[Info-vax] Native compilers

[chris]

On 03/08/22 15:10, John Reagan wrote:
> On Monday, March 7, 2022 at 7:46:02 PM UTC-5, chris wrote:
>> 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.
> The VAX is pretty clear.  The correct behavior is:
> - Load 32-bits from memory from address contained in R7, place into temporary
> - Increment R7 by 4
> - Store temporary in R7
>
> We just deferred the increment until after the store by mistake.
>
>>>
>>> MOVAL (R3)+,(R3)+
>> Again depends on when the autoincremnt happens in the sequence...
> VAX architecture defines the behavior exactly.  The human brain?  Not so much.  :)
>

As one would expect and pdp11 and 68k worked the same way, as
it's written in fact...

Chris'