[Oberon] FJump and FixLink

Jörg Straube joerg.straube at iaeth.ch
Sun Sep 23 16:11:11 CEST 2018


Andreas

The RISC5 processor has an addressbus of 24 bits («adr» in RISC5.v = 16 MB possible).
As the PC and branch displacements are on word boundary, they have 22 bits («disp» in RISC5.v)

So, basically, C24 is wrong in the first place, as displacements can not be larger than 22 bits (0..21).
Effectively only +/- 21 bits, as the MSB (bit 21) signals negative branches.
But C24 does not harm as it correctly handles the negative values.

This explains how ORG.fix() could have been implemented.

Now, ORG.FixLink and ORG.FixLinkWith handle chains of jump addresses to be fixed. The values in the chain are only positive and they are smaller than ORG.maxCode.
Principally, «MOD maxCode» would be enough. For efficiency, any power of 2 bigger then ORG.maxCode would do, so MOD 40000H does not harm.

In short, I would have coded the procedures as follows:

  PROCEDURE FixLink*(L: LONGINT);
    VAR L1: LONGINT;
    BEGIN
      WHILE L # 0 DO L1 := code[L] MOD 2000H; FixOne(L); L := L1 END
    END FixLink;

  PROCEDURE FixLinkWith(L0, dst: LONGINT); (* used for «UNTIL» *)
    VAR L1: LONGINT;
    BEGIN
      WHILE L0 # 0 DO
        L1 := code[L0] MOD 2000H; fix(L0, dst - L0 - 1); L0 := L1
      END
    END FixLinkWith;

br
Jörg

Von: Andreas Pirklbauer
Gesendet: Sonntag, 23. September 2018 12:26
An: ETH Oberon and related systems
Betreff: [Oberon] FJump and FixLink

  > Thanks Jorg. Good pointers.
  >
  > > - are branch offsets in words or bytes?
  >
  > In words.
  >
  >> - how much RAM does the board have?
  >
  > 1MB SRAM.
  >
  > Now I see.
  > To address 1MB we need = 20 bits If we present offset in words, we need = 20 - 2 = 18 bit. :-) 


Just to add another remark on this topic. The official Oberon-07 compiler is in fact inconsistent:

- in ORG.FixLink:       L1 := code[L] MOD 40000H;  (*18 bits*)
- in ORG.FixLinkWidth:  L1 := code[L0] MOD C24;  (*24 bits*)

Does anyone know why?

PS: I would prefer to use C24 throughout. That way the compiler also automatically 
works ob boards with larger memories.


--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20180923/11e2a62e/attachment.html>


More information about the Oberon mailing list