[fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....

[Bernd Oppolzer]

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  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>