
****************************************************************************

  Auszug aus GEMX.DEC

  PROCEDURE LENGTHEN(* ProcNum:28 *)(REAL);

****************************************************************************

proc code, procnum = 28, entrypoint =     0H, number of bytes = 76
 DECODE --------                        INSTRUCTION
     0H        4E56 0000                LINK    A6,#0000H
     4H        48E7 E000                MOVEM.L #E000H,-(A7)
     8H        202E 0008                MOVE.L  0008(A6),D0
     CH        E398                     ROL.L   #1,D0
     EH        2400                     MOVE.L  D0,D2
    10H        0280 00FF FFFF           ANDI.L  #00FFFFFFH,D0
    16H        0282 FF00 0000           ANDI.L  #FF000000H,D2
    1CH        6612                     BNE     [12H] = 00000030H
    1EH        7000                     MOVEQ   #00H,D0
    20H        7200                     MOVEQ   #00H,D1
    22H        48EE 0003 0008           MOVEM.L #0003H,0008(A6)
    28H        4CDF 0007                MOVEM.L (A7)+,#0007H
    2CH        4E5E                     UNLK    A6
    2EH        4E75                     RTS
    30H        E68A                     LSR.L   #3,D2
    32H        E288                     LSR.L   #1,D0
    34H        E292                     ROXR.L  #1,D2
    36H        0682 3800 0000           ADDI.L  #38000000H,D2
    3CH        2200                     MOVE.L  D0,D1
    3EH        E688                     LSR.L   #3,D0
    40H        E699                     ROR.L   #3,D1
    42H        0281 E000 0000           ANDI.L  #E0000000H,D1
    48H        8082                     OR.L    D2,D0
    4AH        60D6                     BRA     [D6H] = 00000022H
  checksum: o.k.

****************************************************************************

 Leider ergibt diese Proz. 'krumme' Verlngerungen
 (z.B. LONG (3.200000) = 3.200000048...).
 Der Grund ist das in REAL-Zahlen eingebaute arithmetische Aliasing:
 In der hheren Genauigkeit gibt es natrlich i.a. Zahlen, die wesentlich
 nher am wahren Wert (im Bsp.: 3.2) liegen als die der niedrigeren.

 Abhilfe: Entweder ein anderes LENGTHEN, oder folgender Vergrberungs-Trick:
  (Warum das funktioniert wei allein der groe Compi...)

PROCEDURE Long (r: REAL): LONGREAL; (* Fr fast 'exakte' Verl. mit Dez.-00.*)
 BEGIN RETURN (LONG (r * 1.0E6) / FLOATD (1000000)) END Long;

 Sonst bliebe wohl nur noch der (ziemlich lahme) Umweg ber die Dezimalen...

 brigens:
 Die Differenz der Offsets (Bias) der Exponenten (zw. REAL & LONGREAL)
 betrgt   1023 - 127 = 896 = 7 * 2^7 (daher kommt 38000000H = 0011100...).
 Formate:  REAL: v,e8,f23  => Zahlbereich 2^24 ~ 16000000 => max.  7 Stellen
       LONGREAL: v,e11,f52 => Zahlbereich 2^53 ~ 8* 10^15 => max. 16 Stellen

****************************************************************************

