Gluk in ALASM

ZXNet echo conference «code.zx»

From Felix Knyazev To All 8 November 2000

Greetings, All! ╔══════════════════════════════ ════════════════════════════════ ║Forward from Felix Knyazev ╠══════════════════════════════ ════════════════════════════════ ║Aria: REAL.SPECCY ║From: Alexey Kravchenko (2:5068/2.125) ║To: All () ║Topic: "Gluk in ALASM" ║Date: Tuesday 7 November 2000 (11:39:08) ╚══════════════════════════════ ════════════════════════════════ ======================= start of the forward ======================= Hi, All!!! A couple of months ago I discovered such a glitch in Alasma (tested on versions 3.8, 3.9, 4.1, 4.2): in short, if during assembly in page jump addresses (#7FFF and #BFFF) the label has not yet been calculated, then its low byte when in the subsequent calculation is lost :_(. An example for understanding: ORG #BFFF METKA EQU #3456 DEFW METKA Now we look at everything with STS: #BFFF:#56 #C000:#34 That is, everything is as it should be. Now let's change this piece of code: ORG #BFFF DEFW METKA METKA EQU #3456 Now let's look at STS: #BFFF:#56 #C000:#00 (!!!) The glitch, of course, is not global, but it spoiled my nerves a lot... For this I say goodbye, with respect Alexey Kravchenko AKA kurleson^hs^cpu -+- Terminate 5.00/Pro + Origin: HoRrOr$oFt^CpU (2:5068/2.125) ======================== end of forward ======================= Best regards, Felix. [I.ZX] 85