1. 18

  2. 6

    It makes my heart ache that interesting ideas like these have largely been extinguished under a tsunami of ’70s era Unix sludge. Oh well.

    1. 6

      Exec was the “kernel” of the Amiga operating system, though it was different from what most people might consider a kernel nowadays.

      It handled multitasking, message-passing, and other core stuff like that, but the operating system was very modularized into “libraries”. Libraries were shared bits of functionality but they were loaded explicitly at runtime and could maintain shared state between different library users and were generally singletons. Think of them more like Oberon modules in the Oberon System…Exec was, from the programmer’s perspective, just another of these modules.

      Libraries (modules) were loaded anywhere in memory and everything was written using position-independent code. This was true for all libraries, except one: Exec.library was loaded at a fixed address (ExecBase, 0x00000004). You then used that known entry point to discover the rest of the system.

      (Some very naughty/lazy programmers would use fixed addresses for other libraries like Intuition.library because they were almost always loaded in the same place by a given version of the OS, but this was undocumented and it did change between versions…)

      Exec was written almost entirely in M68k assembly and powered a seamless preemptive multitasking operating system on a 7MHz machine with 256KB of memory. It was really impressive.

      AmigaDOS was not Exec, but rather a port of large portions of TRIPOS on top of Exec. AmigaDOS handled filesystems, the CLI, and so on.

      It was done this way because CAOS, the original vision for the Amiga’s operating system wasn’t going to be ready in time for the release of the system. AmigaDOS was originally written in assembly and BCPL as inherited from TRIPOS, and there were some quirks you had to deal with because of that.

      Exec, or something like it, would be a beautiful model for a modern embedded OS. I’d say RTOS, but Exec was not designed in such a way that would easily provide real-time guarantees, I don’t think, though it did provide a pretty sophisticated priority-based scheduler. I think that the time needed to schedule a process was still O(n) though, which would preclude the RT part of RTOS. I absolutely could be wrong though…

      1. 3

        I found the Amiga system software to be three different things bolted together. You had the low level kernel, Exec, written in 68000 assembly code (and very elegant). You had the filesystem, AmigaDOS, a port of TRIPOS written in BCPL (and it showed, with “handles” that were really pointers divided by 4) and the user interface, Intuition, most likely written in C (and again, it showed).

        One neat aspect of Intuition was a “gadget”—a few very low level UI elements you could reuse. At the bottom you had a boolean gadget (think button), a proportional gadget (think scroll bar, but it could also work in 2D) and a text gadget. From there, you could build all other types of gadgets.

        I never did much with the filesystem stuff—it wasn’t quite as fun as Exec, Intuition or even the low lever graphics stuff.

        1. 2

          dos.library was perhaps the ugliest part of AmigaOS1.

          Fortunately, it got a massive overhaul in AmigaOS2, with a much more reasonable API.

        2. 1

          Exec.library was loaded at a fixed address (ExecBase, 0x00000004).

          Careful, 0x4 points to execbase. It isn’t execbase. Exec typically is in RAM or in ROM.

          It’d be in RAM if functions have been hooked (e.g. to fix bugs via setpatch) or if FAST is faster than ROM, for performance reasons.

          1. 2

            Touché. In my defense it’s been a long time for some things. I even call little patch scripts that I write as shims for other things “setpatch” for that reason…

          2. 1

            I don’t think, though it did provide a pretty sophisticated priority-based scheduler.

            No “nice levels”, but it did have priorities, the hard kind. If a higher priority process becomes runnable, it preempts lower priority processes.

            Ultimately, TripOS itself was a RTOS.

          3. 5

            Amiga Exec was my first exposure to an actual operating system and spoiled me forever (but let’s not mention AmigaDOS, ugh).

            My first attempt at getting OO to work was a bit of C-Macro wrapping around the shared libs. This was both promising and ugly, and after a quite a bit of procrastination of the “do I really want to bite off that much” prompted me to implement an Objective-C pre-processor and runtime, because I just knew I didn’t want to program in anything less.

            1. 4

              Man, so many incredibly elegant things about the Amiga architecture on so many levels.

              Exec and Intuition were the first two actual APIs I ever learned, not counting the old school assembly language jump offsets of the 8 bit era :)

              1. 4

                I love the Amiga, you know that.

                But I wouldn’t describe Intuition as elegant…It wasn’t until BOOPSI and MUI that things really got beautiful there, IMHO.

                1. 3

                  I suppose you’re right. I just loved the whimsical way the API was designed. GimmeeZeroZero() will always be a favorite :)

                  1. 3

                    Hah, thank you for that. Brought back some fond memories.

                    1. 2

                      What did GimmeZeroZero do?

                      1. 5

                        Intuition was the low-level windowing API on the Amiga. It was closer to, for example, raw Xlib than it was to a higher-level toolkit like Motif or whatever.

                        The “system-drawn” portions of windows were part of the same notional bitmap as the content (“user-drawn”) portion. Nothing stopped you from drawing over the title bar or the resize gadget or whatever and so you had to be aware to offset your drawing operations from the window widgets.

                        GimmeZeroZero was a flag you could specify when creating a window that would cause the system to create a distinct layer for the window decorations and give the content portion of the window its own distinct layer. That way you could draw on the window without worrying about corrupting the window decorations. The name was because you wanted coordinate (0,0) to refer to the content portion, not the upper-left portion of the window decorations.

                        1. 3

                          Thank you.

                          1. 2

                            Thanks a bunch for this it’s been way too long and a lot of this stuff has bit rotted.

                            One day I will have time to cozy up to the RKM again and do some Amiga coding :)

                          2. 1

                            Unfortunately I don’t have time to go hunting it down in the Intuition Reference Manual, but I seem to recall that it gave you the chunk of memory representing 0,0 in the current display object (e.g. Window, screen, etc.)

                            My memory is fuzzy though so don’t bet the farm on this :)

                            1. 2

                              See the other reply from lord dimwit on this comment thread

                    2. 2

                      To call functions in an Amiga library, put the Library base into register a6, then jsr functionoffset(a6).

                      To get a library base, open it via OpenLibrary() from exec.library.

                      To get execbase, just move.l $4, a6.

                      Also relevant:

                      Exec function documentation: http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_2._guide/node0322.html

                      Commented disassemble of exec v33 (AmigaOS 1.2): http://wandel.ca/homepage/execdis/exec_disassembly.txt