27th March 08:57
Poplog OS X test
OK. So we are getting a pattern here. When it reaches the syntax word
"=>", defined in $popsrc/pop11_syntax.p it should complete VM code
construction, translate to machine code, construct a procedure record
containing the machine code, and run the procedure.
The definition of '=>' shows where
SyspushQ: <true> came from:
define syntax 12 =>;
pop_expr_inst(pop_expr_item); pop11_FLUSHED -> pop_expr_inst;
sysPUSH(if popclosebracket == popclosebracket_exec then
"false" endif); sysCALL("sysprarrow");
";" :: proglist -> proglist
I guess sysCALL is not being traced, but my hunch is that it would
have run since many system procedures have to run in order to produce
the results so far.
I expect the same crash will happen with
or pehaps even just
depending whether that causes creation and execution of a
null procedure or whether that is optimised away, because
there's an empty codelies.
When it gets to the ";" the compiler recognises that it's the end of
the 'statement' (see syntax diagrams in REF POPSYNTAX -- which only
works in Ved, alas).
See also procedures like:
which includes this:
quitunless(nextitem() == ";");
sy***ECUTE() ;;; to execute the code endrepeat;
(I assume PL Chop() does something like tl(proglist) -> proglist
The procedure sy***ECUTE is defined in vm_control.p.
It's complex and low level.
This bit of it seems to be doing the actual compilation: Save_current_pcr();
pcr!PCR_DLEXPR_LIST -> tmp,  -> pcr!PCR_DLEXPR_LIST; Try_assemble(pcr);
tmp -> pcr!PCR_DLEXPR_LIST;
;;; if not assembled then can't execute the code yet
returnunless(pcr!PCR_PDR_REC ->> p)
the completion of the construction of the procedure record is
indicated by the procedure being assigned to 'p',
This is presumably cleaning things up after compiling the
expression into a procedure:
;;; re-initialise pcr/lblk
 ->> lblk!LBLK_SYMBOL_LABELS -> pcr!PCR_NON_LOCAL_LABELS;
Ensure_writeable(0 :: ) ->> pcr!PCR_CODE_LIST -> vm_code_end;
false ->> pcr!PCR_PDR_REC -> vm_code_penult;
 -> vm_reprocess_instrs;
_S_NONE -> _simstack;
_0 -> _vm_stack_count;
then the procedure is run, at last:
;;; run the procedure with pop_vm_exec_apply (defaults to fast_apply,
;;; but redefined by Popc).
[NB: I have never looked at those portions of the system sources
previously. But my guess is that of the OSX team can insert some
trace printing in there they can tell whether it completes the
compilation and fails on the execution (pop_vm_exec_apply),
or whether it crashes before compilation is complete.]
I don't think any of the other trace output is sufficient
to tell the difference between those two options.
My hunch is that the new procedure is not being compiled properly. There
could be a problem with the 'run time assembler' even though the system
assembler that was used to build the poplog system is working fine
(presumably when running on a linux pc).
I.e. until now all the porting work will have focused on getting the
code generated that will produce a running system.
Once the system is running the incremental compiler has to be able to
generate machine code 'on the fly', and that's a totally different
process (at least the last stages are totally different) from generating
assembler files to be cross compiled.
Some extra tracing may help to identify whether the problem is
wrong machine code being assembled or something else.
unless I have gone down a false trail!