[CDG5] Process Manager

[Elliot Nunn]

*Almost* round-tripping. All procedures and globals are placed
correctly, and there are only one or two compiler niggles left. But a
very small number of jump table entries are getting transposed,
resulting in a few red speckles in vbindiff.

> On 30 Dec 2018, at 4:52 pm, Elliot Nunn <elliotnunn at fastmail.com> wrote:
> 
> 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
> 
> _______________________________________________
> cdg5 mailing list
> cdg5 at ucc.asn.au
> https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/cdg5