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