[Info-vax] Native compilers

[Johnny Billquist]

On 2022-03-08 16:20, abrsvc wrote:
> On Tuesday, March 8, 2022 at 10:10:52 AM UTC-5, xyzz... at gmail.com 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. :)
> Does is make sense to increment R7 at all?  It seems that this step should be eliminated as it will be overwritten anyway.

That was part of the point John was making.
To quote him again:
"Yes, that auto-increment is worthless and serves no purpose, but it is 
a legal VAX instruction."

And yes, the step could be eliminated, but the bug was that it was 
applied at the wrong time.

> The case of the MOVAL (R3)+,(R3)+ is a little more convoluted...
> 
> Get the address pointed to by R3 and place in temp, add 4 to R3.
> Place temp into address pointed to by R3 then add 4 to r3
> 
> The above is correct, I think.  But yes, it tests the mind as to what this is actually doing... and why!

Yes. That is correct. And that can definitely be useful sometimes.

There is a kind of single linked list where you'd want that. The list 
head have a pointer to the first and the last element as a two word 
entry. All entries in the list just have a single pointer to the next 
element, and of course the last element contains a 0. If the list is 
empty, the last element pointer will point to the head element pointer.

If you have a bunch of such list heads, you'd initialize them this way. 
Basically:

   CLRL  (R3)
   MOVAL (R3)+,(R3)+

loops for as many list heads you have.

I'll leave insertion and removal from such a list for others. I can tell 
it's a very common type of list for everything inside RSX, and thus I 
suspect you'll find them inside VMS as well...

   Johnny