Re: Some more patches for GCC on NetBSD/VAX coming soon...

[Johnny Billquist <bqt%update.uu.se@localhost>]

On 2016-04-02 03:26, Mouse wrote:
> > > Lots of PDP-11 instructions [...]
> > Not sure where the PDP-11 came into this, [...]
>
> Probably me spazzing.  When writing that email, I somehow got it into
> my head that the original example was for the PDP-11.

:-)
Yeah, Paul presented a nice piece for the PDP-11 very much in the same 
vein, which probably stuck. The original was the 6502, but the question 
was (I guess) more generically if GCC use such tricks.

> > Let's say that you have a MOVL (R2),(R3), and you might want to skip
> > it, so you need an instruction to precede this instruction sequence.
>
> > Now, a MOVL (R2),(R3) will in fact take three bytes.  The MOVL is one
> > byte, the (R2) is one byte, and (R3) is another byte.
>
> Yes.  D0 62 63, if my reading is correct.

I was way too lazy to actually check the opcodes. :-)

> > Now, what instruction would you prefix this, in order to eat those
> > three bytes?  No matter what it is, this prefix instruction that
> > should eat that sequence will then unavoidably interpret the MOVL
> > instead as an argument.
>
> Only if you insist on using only one byte for the prefix.  (Which,
> admittedly, if the point is to save bytes, you want to do, since a BRB
> around it takes only two bytes.)

With a couple of exceptions all opcodes on the VAX are one byte.
But yeah, once we get to several bytes, then we might as well just have 
had the BRB instead.

> > If you look at the opcode for MOVL, what is that when interpreted as
> > an argument?
>
> Word displacement deferred, off r0: @W^xxxx(R0).  I think.

That happened to be rather convenient. Figures that I would pick one 
that was more or less possible. :-)

> > It will (hopefully) be something that don't consume more than two
> > additional bytes,
>
> Conveniently, it consumes exactly two additional bytes. :-)

My luck.

> Inconveniently, it requires that memory at offset 0x6362 from r0 be
> readable; depending on the instruction you use as the prefix, it may
> require more memory to be accessible.  And, of course, this is all
> MOVL-specific, and works only if neither of the MOVL operands takes
> more than one byte - or the byte after the first two can also be taken
> as an opcode without causing too much trouble.

Right. You can of course prefix with something that takes more than one 
argument, and thus consumes more as well, but it all becomes very 
complicated.

> Yes, this is far less useful on the VAX, possibly except for a few
> special cases.  It could make for some awesomely obfuscated code,
> though. :-)

It would be wonderfully obfuscated. But figuring out actually useful 
combination of bytes seems like way more complexity than it ever is 
worth. And your point about memory referencing potentially also causing 
traps is also a good point. There are way too many problems trying to do 
this safely on a VAX.

	Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol