I won't be tweeting too much today because I have some actual work to do on both my emulator project (tiny8086 ported to Amiga OS and other big-endian systems) and setting up some job interviews for next week.

I mostly wanted to tweet notes yesterday about my Amiga OS research.

I wanted to preserve my notes for myself & others. I'm very happy with the status of GCC for Amiga OS and for NetBSD on m68k, the other OS I'm especially interested in helping to maintain to run on Amiga computers (original and emulated). There's a new patch set I want to merge.

"[PATCH 0/4] Eliminate cc0 from m68k" by Bernd Schmidt, link to first email to #NetBSD list here: https://gcc.gnu.org/legacy-ml/gcc-patches/2019-11/msg01028.html

This is very esoteric, but also important for code quality, esp. C++ code. "cc0" is an obsolete API that the different CPU backends need to switch away from.

I was aware that the VAX backend used the cc0 API, and I did some work (hopefully still on one of my ZFS pools) to try to change the VAX .md file to use the newer style, but this is some really advanced coding. GCC has a custom machine description language that it processes.

And here's the post to the GCC patches list, "Deprecating cc0 (and consequently cc0 targets)" by Jeff Law, adding the patch to the current GCC to warn that m68k, vax, and the other cc0 targets are deprecated and will be removed if they don't get fixed: https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg01256.html

So after I finish my tiny8086 project, I would like to work on integrating Bernd Schmidt's patch set for m68k into the Amiga OS and NetBSD source trees, to see if it generates hopefully better and less buggy code for both OS's. I'd really like to study such a tricky thing to fix.

And if you'd like to know more about the "CC0" to "MODE_CC" transition that I just described, see this Wiki page: https://gcc.gnu.org/wiki/CC0Transition

That's really esoteric stuff, but I think it'll have a positive impact on the community. Bebbo's GCC Amiga OS repo is being actively maintained, which is wonderful: https://github.com/bebbo/amiga-gcc 

After integrating the MODE_CC patch, I'd like to try to add a feature specific to AmigaOS.

Here's a thread I wrote yesterday about some longer-term thoughts I had for extending Amiga OS, especially when being run in emulation or on an FPGA. I talk about SAS/C and Lattice C a little bit: https://twitter.com/jhamby/status/1281090018816036865?s=20

Here's the thread I was looking for: what GCC is missing is support for "pragma libcall". https://twitter.com/jhamby/status/1281636473582678022?s=20

On m68k, it's missing support for calling functions with parameters in registers instead of on the stack, something the x86 backend does happily support.

Without #.pragma libcall, there's still a way you could more efficiently call Amiga OS functions from GCC than with the current "amiga.lib" stub function approach, which would be with inline assembly functions. GCC has very strong inline assembly support for copying to registers.

So I think it may be possible to get GCC to handle at least the Amiga OS library calls as efficiently as SAS/C does without making any changes to GCC itself. That would be ideal. But even better would be if GCC let you add function attributes for __regparm like on x86 and others.

One very good thing about the current GCC for m68k is that it does have the new-style ELF C++ exception unwinding, which I had to learn far too much about in my past attempt to fix for VAX. It's the only thing that the Itanium contributed to the industry: http://wiki.dwarfstd.org/index.php?title=Exception_Handling

The Itanium is an absurdly complex VLIW chip that Intel and HP spent billions of dollars developing in an attempt to make something difficult to clone. I was going to say they probably got patents on it, but they actually lost a patent battle over Itanium: https://www.zdnet.com/article/intel-loses-itanium-patent-ruling/

From what I've learned about Itanium through my interest in OpenVMS, it has a very difficult instruction encoding scheme for writing debuggers and other tools. They designed a general-purpose method to describe C++ code such that an exception can pop the stack up to the handler.

It was so nifty, compared to the way GCC was previously doing it (with hidden calls to setjmp() and longjmp() for try() and catch() behavior, a UNIX-style way to pop the stack from C code that Symbian OS also used for their non-standard exceptions in their dialect of C++), …

…that the Linux and *BSD communities and everyone else using GCC on ELF targets adopted it as the standard way of implementing C++ exceptions. So if you want to know how "zero-overhead" C++ exceptions work, you have to read the "C++ ABI for Itanium" docs: https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html

In a nutshell, the way it works is the compiler generates some extra read-only data for every program that uses C++ exceptions describing the state of the stack and register usage such that it can be unwound safely back to the "catch" block that can handle the exception.

All of this knowledge came flooding back to me yesterday while reading the long thread on an Amiga OS forum about the GCC port I mentioned and the most recent post was by the author of the port explaining why C++ programs are now slightly bigger than they were under GCC 2.9x.

It's going to blow people's minds when the GCC toolchain for Amiga OS gets updated (hopefully I can assist with this process, but someone will do it soon enough) to build & use "libgcc.library" & "libstdc++.library" to make appropriately tiny Amiga executables, like SAS/C 6.58.

What am I talking about? Of course they would be "gcc.library" and "stdc++.library" to fit the Amiga naming conventions. You can't link that stuff as a shared library yet because it isn't standardized (on Amiga OS 3.x). So programs with any C++ usage will be large by Amiga terms.

Making your own shared libraries (as opposed to using someone else's) on Amiga OS was always tedious and confusing, but having studied how ELF works on UNIX, I can tell you that it's about 1/10th as confusing as ELF. They're also friendlier than the old "a.out" Linux shared libs.

The very old versions of Linux supported "a.out" binaries, which was a very simple format that goes back to the original UNIX (and MINIX also used). When Linux added shared libraries, it was a very inflexible system where you had to reserve fixed memory addresses for them!

The whole system was completely ridiculous, but efficient at runtime, especially for an old 80486-class PC with 8MB or so of RAM and someone who has to justify using Linux instead of, say, Windows 3.1, which has a similarly hardcoded DLL system (although DLLs can be relocated).

On the Amiga, ".library" files are generally position-independent code so they can be ROMmable, but I think they can have relocations if you load them from disk. "PIC" code is what you get with GCC when you compile with "-fPIC", which on ELF systems reserves an extra register.

There's a whole complicated machinery in the ELF runtime linker for "lazy linking" so that when your program brings in a giant shared library with many hundreds of entry points, it doesn't sit around matching up every call to the address of the entry point in the shared library.

Instead, there's usually a jump table somewhere that's initially filled in with a call to the "lazy linker" that patches up the reference to the function that the program is trying to call in the jump table itself, before calling it for the first time, so future calls are fast.

All of this machinery is really advanced and tricky stuff, so you definitely have to be aware of what your particular combination of CPU architecture, kernel, system libraries, and compiler is assuming in terms of preserved and volatile registers, fixed registers, stack, etc..

The reason I spent so much time looking at all this stuff as a hobby 6 years ago was to distract myself from being unhappy with the state of things in the computer industry and living in Silicon Valley. But it was also incredibly educational. I just didn't have anywhere to share.

At the time, I thought there was no point at all in doing anything with Amiga OS any more, because I didn't think it had anywhere to go after all the confusion with the PowerPC fork and 3.5 and 3.9 and all the hacks and controversy over ownership of copyright and everything.

I didn't think anyone would be interested in talking about m68k stuff, and oddly, none of the people I knew from Google were interested in old computers at that time.

It's very exciting that the Amiga OS 3.1.4.1 update came out, for the people who are still using it as their daily system. So many stability and quality of life improvements. As a hobby developer, I now know the bugs in the older versions I may need to work around, which is nice.

And as I've been saying, I can tell that I'm not the only person who is picking up and revisiting these old systems now, and for similar reasons to me. Nostalgia is one component, but also the challenge of building cool programs in a very constrained environment (to show off).

And we now have fast enough PCs on our desks to emulate a really expensive Amiga experience from the late 1990s in software at a reasonable speed. Admittedly, you could emulate an original 7.1 MHz Amiga *in* the late 1990s on a fast desktop PC (Pentium III), but not much faster.

My #1 reason for being into emulating older machines on newer ones is that I'm tired of the "planned obsolescence" and built-in DRM of the newer systems. That's why I'm not going to ever buy another Apple device (unless they change their ways). Too locked down to recommend.

I'll probably buy a pure Linux phone (and I don't mean Android) before I buy another iPhone. That's not a choice I'd recommend for everyone, but I want to have ownership of the hardware that I buy. The old Commodore computers, the older PCs, and even PowerPC Macs gave you that.

In addition to "ownership" in the sense of lack of DRM, another really core feature of the older computers, going back to the Apple II, Commodore 64, and original PC, is that the makers wanted you to be able to understand the entire PC in its entirety, to be able to master it.

While the Raspberry Pi line is extremely popular, very inexpensive, and was explicitly designed to be like a modern Commodore 64, it's somewhat locked down (closed-source blobs for the VPU and bootloader) and it's too difficult for the average developer to fully grasp in detail.

There's simply far too much detail to learn about a modern multitasking Linux desktop for it to be educational in the way that the 8-bit and then 16/32-bit systems were. Of that era, the Amiga may have had the very best OS in terms of efficiency, robustness, & extensibility.

People who only saw the Amiga as a games console with floppy disks that you could easily pirate maybe didn't take full advantage of "Workbench", the multitasking desktop, but it really influenced those of us who did take the time to learn "AmigaDOS" commands or how to use ARexx.

I never had much use for ARexx, but I definitely taught myself C because of the Amiga and because of UNIX being the big hotness at the time. MINIX was written in C. Linux was written in C. Everyone was learning C and copying ideas from UNIX. So it still feels modern to me today.

So many Amiga OS programs were written in 68000 assembly language and everyone also wanted to learn that and teach themselves that, but it's much more tedious to write programs in 68k assembly, and then of course they're not portable to anything else, or efficient on newer CPUs.

One tip I would give to vintage Amiga hardware collector enthusiasts is that if you want to avoid mysterious crashes and other system instability, the 68060 CPUs are extremely dependent on the quality of the "68060.library" that emulates the opcodes that Motorola removed.

If you're using NetBSD or Linux, the proper emulation functionality for the older CPUs, as well as FPU emulation for CPUs without an FPU, should be handled entirely in the kernel, but on the Amiga, there's a 68040.library or 68060.library that gets loaded at boot time. Hopefully.

Consequently, if you try to boot an Amiga with many ROM variants and disk images with a 68060 CPU, it may not get anywhere at all because of missing 68020 opcodes and no 68060.library. You may need to patch that lib into your Kickstart ROM. I don't even try to use 060 in FS-UAE.

So if you're looking for actual hardware, it's far better to find a fast 68030 or 68040 board, specifically one with an FPU (external for 68030, internal for 040) and an MMU (required for NetBSD/Linux, recommended for Amiga OS), and not one of the cut-down "LC" or "EC" variants.