[raspi-internals] Re: 2op vs 3op ALU operations

  • From: Mathias Gottschlag <mgottschlag@xxxxxxxxx>
  • To: raspi-internals@xxxxxxxxxxxxx
  • Date: Mon, 20 May 2013 15:48:28 +0200

Am 20.05.2013 15:32, schrieb David Given:
Herman Hermitage wrote:
[...]

I hope that's an Algol 68 compiler I can smell brewing! :-)
Unfortunately the Algol 68 compiler is written in archaic Pascal and I
haven't even tried to make it work. Maybe one day.

Good news! I have most of an assembler, some linker support, and the
skeleton of code generation. I even managed to compile my first C
function! It doesn't run, of course...

Some questions:


Firstly, there are a number of instructions that contain a pc-relative
offset. (b, lea, ld, etc.) I've been testing my assembler against the
online disassembler and I notice that I need to add different modifiers
to the offset to make them come out right.

For example:

- the offet for simple b and bl seems to be relative to the *beginning*
of the instruction. (rd = pc + o)

- the offset for comparing b and addcmpb seems to be relative to the
*end* of the instruction. (rd = pc + o + 4)

I've looked at how the disassembler calculates the target address but
TBH don't make much of the code. Does anyone have any clarifications?
(Incidentally, as a feature request: it would be really convenient if
the disassembler resolved the target address in ld rd, o (pc) instructions.)
objdump in the binutils port can do that. I don't remember the exact semantics.


Secondly, in instructions of the form ld rd, (ra + rb); is rb scaled
according to the size of rd? (It would be nice if it wasn't, as I want
to use that instruction a lot for PIC code.)
Yes, rb is scaled.


Thirdly, in order to generate fully PIC code I think I have to offset
all memory accesses via gp (r24). (Because there's no fixup stage when
loading kernels, and we have no control over where in the VC4's memory
the kernel gets loaded, the code must run from anywhere.) This seems
rather painful. Is there a better way?



Other related posts: