[CDG5] Process Manager

[Elliot Nunn]

https://github.com/elliotnunn/CubeE/tree/processmgr-snapshot

I can build the Process Manager! It *almost* round-trips, except that
the linker puts the segments in the wrong order. Once that is fixed I
will be able to clear up any lurking compilation problems.

The commit message is the command to pipe into BuildCubeE. The commit is
very messy, but I wanted to show this part off.

> On 30 Dec 2018, at 11:34 am, Elliot Nunn <elliotnunn at fastmail.com> wrote:
> 
> Didn't learn my lesson, either. I just spent 30 minutes learning that
> '-opt full' *might* somehow affect code generation.
> 
>> On 30 Dec 2018, at 11:31 am, Jason Duerstock <jason.duerstock at gmail.com> wrote:
>> 
>> Man, you should've asked.  "Check the compiler flags" would've been the first thing I thought of.
>> 
>> On Sat, Dec 29, 2018 at 9:51 PM Elliot Nunn <elliotnunn at fastmail.com> wrote:
>> Like Max, I had a bit of a code-generation problem last night. Thought
>> I'd share it for your entertainment.
>> 
>> As a big part of getting a System build to work, I am recreating the
>> makefiles for the Process Manager. The Process Mgr has a very novel
>> runtime (it actually gets loaded from 'scod' resources by the Segment
>> Loader). With not many clues around about how to build it, I decided
>> that I should take a deep dive at this point and get it round-tripping.
>> System 7.1 seems to be a good fit.
>> 
>> For context, the build is currently producing about 1/2 to 2/3 of a
>> System file, albeit of dubious quality.
>> 
>> Here is the function in question.
>> 
>>        /* CheckUnitTableEntry.  See if the UNITTABLE entry that this driver would occupy
>>         * is acceptable.  For now, just checks whether entry is already in use.
>>         */
>>        OSErr
>>        CheckUnitTableEntry(short resourceID)
>>                {
>>                register DCtlPtr        dCtlPtr;
>>                DCtlHandle                      dCtlHdl;
>>                OSErr                           result;
>> 
>>                result = noErr;
>>                dCtlHdl = (DCtlHandle) UNITTABLE[resourceID];
>>                if ( (dCtlHdl != nil) && ((dCtlPtr = *dCtlHdl) != nil) && ((dCtlPtr->dCtlFlags & DOpened) != 0) )
>>                        result = portInUse;
>> 
>>                return(result);
>>                }
>> 
>> UNITTABLE is defined as (*(Handle **)(0x11C))
>> 
>> The unit table access was compiling to "EXT.L D0; MOVE.L $11C,A0; MOVE.L
>> $0(A0,D0.L*4),A3" when I wanted "EXT.L D0; MOVE.L $11C,A0; ASL #2,D0;
>> MOVE.L $0(A0,D0.L),A3". I fought with this until 1 am, changing headers,
>> types and compiler versions to no avail. I found that the same motif
>> appears in two or three places in that segment, and the ASL persists up
>> to System 7.1.2, after which it was refactored out of existence.
>> 
>> This morning I was about to email the list for help, when in a testament
>> to the "starting really hard at a problem" methodology, the answer came
>> to me. "MOVE.L $0(A0,D0.L*4),A3" is a very fancy-looking addressing
>> mode, I thought. It wouldn't work on a vanilla M68k... Oh! System 7.1
>> *does* run on a 68000, because it supports the Plus and Classic. (I
>> should know, because I grew up using it on a Classic.) The C compiler
>> was being run with the -mc68020 argument because I copied the makefile
>> from the ROM build. Now fixed!
>> _______________________________________________
>> cdg5 mailing list
>> cdg5 at ucc.asn.au
>> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5
>> _______________________________________________
>> cdg5 mailing list
>> cdg5 at ucc.asn.au
>> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5
> 
> _______________________________________________
> cdg5 mailing list
> cdg5 at ucc.asn.au
> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5