Jonathan corrected one of my misinterpretations.
> > > On OS X we get this results:
> > >
> > > SyspushQ: sysexit
> > > SyspushQ: (
> > > SyspushQ: )
> > > SyspushQ: ;
> >
[AS]
> > That suggests to me that popautolist is working, the macro bye got
> > compiled, and bye ran the commands to put those four words on the
> > stack.
>
> We have no evidence that bye was compiled: only that the first pass
> of the compiler ran, and planted the VM instructions into the codelist.
> We don't yet know if the codelist was correctly compiled into machine
> code.
Correct. I should have said only:
That suggests that
1. "bye" was not found in the dictionary to be pointing to
an identifier (its identprops was "undef")
2. that triggered a search for an autolodable file 'bye.p'
using popautolist (a list of autoloadable directories).
3. such a file (defining "bye") as a macro was found in
$usepop/pop/lib/auto/bye.p
4. the file appears to have been read in, and the lexical
analyser parsed it OK, ignoring the comment at the beginning,
and recognising the start of a macro definition
section;
define global macro bye;
"sysexit","(",")",";"
enddefine;
endsection;
5. Partial compilation to the Poplog virtual machine level seems
to have gone as far as the end of the second line.
That suggests to me that a LOT of the *mechanisms* are working,
including the treatment of proglist as a dynamic list, the interrogation
of the OSX directory structures, reading in of a file as a byte stream,
breaking it up into a text item stream (using incharitem, which is
quite a complex procedure).
> We certainly don't know if the "bye" macro ran. (That would require
> it to *do* the pushQ pseudo-ops, at compile time, whereas Indira's trace
> shows what was happening at macro-compile time, not at compile time.)
Agreed.
> I suspect that the MacOS porting team have now done what I would find
> the hard part -- and the port is now in a state where a lot more of
> us (with experience of the compiler and code-planting stuff) will be
> able to help.
Agreed.
My suggested tests were an attempt to identify whether much simpler
operations than finding and compiling an autoloadable file were
working -- and it seems they don't work, though probably it
is very close.
Perhaps the main thing that is NOT working is completion of compilation
of an expression, or maybe an expression sequence, i.e. what is
done by sysENDPROCEDURE
From REF VMCODE:
sysENDPROCEDURE() -> p [protected procedure variable]
Causes the procedure for which code is currently being generated
to be produced as an object p, with pdprops and pdnargs as
specified by the arguments to sysPROCEDURE. p is returned as
result, and the code list stacked up by the last sysPROCEDURE is
restored to be the current codelist. popexecute is restored to
its value before the previous sysPROCEDURE.
...etc....
See next message.
Aaron
|