[Info-vax] Native compilers

[chris]

On 03/05/22 18:05, John Reagan wrote:
> As a follow-up and something else to focus on...  As we continued to do more testing of the native
> Macro-32 compiler, we had various ACCVIOs and LIB$GET_VM errors on programs that used macros.
> It had no clear pattern other than perhaps something to with macro processing.  It wasn't clear if it
> was part of the macro body scanning or macro expansion.  [We're using DELTA to debug these things
> at the moment, the symbolic debugger is almost ready but it didn't like debugging a full MACRO.EXE
> image.]
>
> At some point it felt to me that perhaps the cross Macro-32 compiler was unable to compile the native
> Macro-32 compiler [such is life in the world of bootstrapping compilers].  We finally found the faulty instruction
>
> MOVL (R7)+,R7

That's interesting. In theory, it's loading what R7 points to into R7,
but the result depends on when the autoincrement takes place, after the 
initial (r7) load, or at the copy of R7 in the destination field ?.
Perhaps not all architectures follow the same path hence the bug.

Never did much vax macro, but some years programming macro 11 and
since just about any instruction works with any address mode if it
sounds sensible, you can do some weird and impenetrable stuff with
the PDP11 instruction set.

>
> Yes, that auto-increment is worthless and serves no purpose, but it is a legal VAX instruction.  That
> particular one is used in 5 different places (perhaps cut-n-pasted years ago?  This stuff is late 1970s
> vintage code).
>
> So where do you think a broken compiler would insert the "increment R7 by 4"?  LOL.  We removed the
> autoincs from the operands and all is working now.  Of course, we'll fix the Macro compiler.
>
> The x86 is actually the first non load/store architecture that the Macro compiler has to deal with.  We
> had to make some design changes to try to incorporate memrefs directly into the instruction that
> performs the operation.  The MOVL path in the compiler essentially tries to fetch the first operand into
> the second operand and then handle the autoinc if needed.  We do that on all targets.  Other instructions
> with that pattern might look the same but are treated differently.
>
> And while I was looking around for other strange/exotic VAX instructions, I bumped across this one
> (which ironically we got right since we used some temporary registers)
>
> MOVAL (R3)+,(R3)+

Again depends on when the autoincremnt happens in the sequence...

>
> Again, a legal VAX instruction, and one that will hurt your brain thinking about that it is doing (it is in
> code that is initializing some self-referencing data structures)


Perhaps check out the context switching code for the PDP11
version of the XINU operating system :-)...

Chris