[fpc-devel] Episode 4. Addressing and it's limits Part Two

steve smithers stevie at collector.org
Wed Feb 8 00:13:39 CET 2012


Episode 4.  Addressing and it's limits Part Two

So we have seen that Base / Displacement will handle addresses up to a
reasonable size.  This should cover most of the requirements.  But there are
still issues that have to be resolved, we need the ability to address more.  The
way we do this is with Index registers.  We get an advantage of unlimited
addressing using index registers but we pay a price that we need to generate
more code.

PROG     CSECT              defines the name of our function
         £START             set up standard linkage
         LR    R12,R15      R15 has the address of PROG, copy it to R12
         USING PROG,R12     Tell the assembler to use R12 as base
         B     LABELB       we want to branch to the exit here 
           <61440 bytes of code goes here>
LABELB   EQU   *           
         £END               return to caller
SAVEAREA DS    18F          save area for standard linkage
           <working storage goes here>
LITPOOL  LTORG
           <constants get defined here>
         END

Taking the simple example we had before, I have added a B (branch or jump to a
label) instruction at the beginning.  It needs to branch over the arbitrarily
large amount of code between itself and the label, but it is more than 4k and
we don't have a base register.
         LA    R1,(LABELB-PROG)/4096
         SLL   R1,12
         B     LABELA-((LABELA-PROG)/4096)*4096(R1)
Explanations first.  Instruction 1 splits the code into notional 4k chunks and
determines which of these chunks holds the label we want.  It places that value
into register 1.  In our case 61440 / 4096 = 15 (/ is integer division, div in
Pascal), so the first instruction loads 15 into R1.  Instruction 2 multiplies R1
by 4096 (Shift Left Logical - 12 bit positions).  R1 now holds the
notional address of the  4k page offset. Instruction 3 is just calculating
Address mod 4096 in pascal terms, the remainder from division by 4096.  Looks
ghastly doesn't it. We wouldn't do it like this in real life, it would be
encapsulated into a macro. So we would call something like $BLONG  LABELB.  The
macro would generate
         LA    R1,15
         SLL   R1,2
         B     PROG+0x022(R1)

The R1 specified on the end is the index register.  What happens is that the
cpu  calculates the address as the base register plus the index register plus
the offset.  We now have the methodology for infinite (well, as infinite as
storage allows) branches.

This complication would need to be considered for other instructions and for
constants too. And not all instructions handle index registers, so we would have
to point temporary registers at these.  But all of this is addressable (sorry
for the pun).

Regardless of what you may believe, FreePascal is not the first compiler to be
implemented on 370 architecture.  Should I tell tell their developers that 370
architecture is too much like a dinosaur to write a 32 bit compiler.  IBM had 32
bit compilers available in the 1960's.  Should I tell them that the architecture
is "broken". It's been around for 50 years and there are hundreds of compilers
available for it.  From FORTRAN to GCC, from COBOL to ADA or from PASCAL/VS to
APL.  All of these were (for the ones that were available from the late
60's) 32 bit compilers.



More information about the fpc-devel mailing list