No need to answer to that ... I understood in the meantime that FPC does
NOT rely on
PUSH and POP instructions. Instead the linear assembler representation
is already fully
CPU specific.
(which makes porting a bigger effort)
Kind regards
Bernd
Am 01.09.2013 16:39, schrieb Bernd Oppolzer:
Am 01.09.2013 16:02, schrieb Mark Morgan Lloyd:
Bernd Oppolzer wrote:
I'm about to head out, so have to be extremely brief.
Thank you very much for that, that made things much clearer for me.
So the compiler relies heavily on the external assembler and the
syntax it supports,
as long as you don't want to do changes to step 2 (that is, change
the linear assembler
representation, which IMO should not be done in the first step).
And: the assembler is not called once, but for every unit.
So here, I think, we have some problems or issues, because, as
already pointed out,
the z-Arch doesn't have PUSH and POP instructions, and I guess that
the outcome
of the linear assembler representation will not be very suitable to
the things that the
z-Arch instruction set provides, although in the meantime there are
some 1500 instructions.
Understanding that, I would now like to have some description of the
linear assembler
representation that FPC generates, that is: it is of course not
target-specific, but it does of
course do some assumptions on the type of the underlying hardware.
Look at the output when using FPC's -a options, for example -aln...
that might in practice need the EXTDEBUG setting during compilation
but I can't go into more detail now.
Push will typically be used to put parameters onto the stack,
otherwise they'll be accessed by indexed operation. The stack frame
is discarded by target-specific code.
Thank you for that; I will take a look at it, although I have some
doubts,
if the output is "target-specific" or "not target-specific" - and if
my understanding
of the linear assembler representation being "not target-specific" is
right.
For that question I would like some statement from the core developers:
how would you deal with a machine that has no built in PUSH instruction?
For example if a function call puts five parameters on the stack,
which is
LD A
PUSH
LD B
PUSH
LD C
PUSH
LD D
PUSH
LD E
PUSH
CALL FUNC
given an accumulator which is target of LD and a PUSH instruction
which PUSHes
the content of the accumulator to the stack.
In my understanding this could be the not-target specific
representation of
the calling sequence
The z-Arch could produce something like
L R5,A
AHI R1,4
ST R5,0(R1)
L R5,B
AHI R1,4
ST R5,0(R1)
L R5,C
AHI R1,4
ST R5,0(R1)
L R5,D
AHI R1,4
ST R5,0(R1)
L R5,E
AHI R1,4
ST R5,0(R1)
here evere PUSH is emulated by the AHI (increment of the "stack
pointer" R1)
and then the indirect store.
But more efficient would be:
L R5,A
ST R5,0(R1)
L R5,B
ST R5,4(R1)
L R5,C
ST R5,8(R1)
L R5,D
ST R5,12(R1)
L R5,E
ST R5,16(R1)
AHI R1,20
still more efficient, if you use other registers (not only R5);
if so, you can maybe store all the values into the stack using only one
instruction (STM) - if the variables are loaded into consecutive
registers (R5, R6, R7 and so on).
That's what the existing compilers on z-Arch normally do - they don't
compile the PUSH instructions one by one as in the first example, but
in contrast,
as there are no PUSH/POP instructions provided by the hardware, they
do some efforts
to do at least only one increment to the stack pointer (like outlined
above) which
is done in the procedure or function prologue.
Now my question is:
do you think that this is a major problem for a FPC port to z-Arch?
Are my assumptions right so far?
Should we start with an easy solution and check the performance
implications later?
Maybe there is a clever solution to that ...
Kind regards
Bernd
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
