My guess is „it is”, still I'd like to become 100% sure.currently processed word anyway).
Here's the „NEXT” of that mentioned fig-Forth:
NEXT: LODSW
MOV BX,AX
NEXT1: MOV DX,BX
INC DX
JMP [BX]
(BTW: anyone could tell me, how should I paste code here to avoid deformation?)
So if I'm correct DX works as Forth's „W” register here.
My question is: then why is it incremented at that moment? And actually it's just half-incremented, since we need cell-stepped incrementation, not by single byte.
My suspicion seems to be confirmed by DOCOL's code (and by similarly looking code of other „DO”-s):
DOCOL: INC DX
DEC BP
DEC BP
MOV [BP],SI
MOV SI,DX
JMP NEXT
From what I understand, incremention of „W” has been splitted into two stages. If I made this, I'd rather insert two INCs into „DOCOL”, leaving original value of „W” untouched (if it may be needed anywhere; it does contain the address of
Does that „split-action” have any merits behind it? Or is it just on the rule: „well, someone years ago made it this way, and then all the followers copied that because it worked doing no harm”?
My guess is =E2=80=9Eit is=E2=80=9D, still I'd like to become 100% sure.
Here's the =E2=80=9ENEXT=E2=80=9D of that mentioned fig-Forth:
NEXT: LODSW
MOV BX,AX
NEXT1: MOV DX,BX
INC DX
JMP [BX]
(BTW: anyone could tell me, how should I paste code here to avoid deformati= >on?)
So if I'm correct DX works as Forth's =E2=80=9EW=E2=80=9D register here.
My question is: then why is it incremented at that moment? And actually it'= >s just half-incremented, since we need cell-stepped incrementation, not by = >single byte.
My suspicion seems to be confirmed by DOCOL's code (and by similarly lookin= >g code of other =E2=80=9EDO=E2=80=9D-s):
DOCOL: INC DX
DEC BP
DEC BP
MOV [BP],SI
MOV SI,DX
JMP NEXT
From what I understand, incremention of =E2=80=9EW=E2=80=9D has been splitt= >ed into two stages. If I made this, I'd rather insert two INCs into =E2=80= >=9EDOCOL=E2=80=9D, leaving original value of =E2=80=9EW=E2=80=9D untouched = >(if it may be needed anywhere; it does contain the address of currently pro= >cessed word anyway).
Does that =E2=80=9Esplit-action=E2=80=9D have any merits behind it?
dxforth <dxforth@gmail.com> writes:
; 8080 FIG-FORTH
NEXT LDAX B ;(W) <- ((IP))
INX B ;(IP) <- (IP)+2
MOV L,A
LDAX B
INX B
MOV H,A ;(HL) <- CFA
NEXT1 MOV E,M ;(PC) <- ((W))
INX H
MOV D,M
XCHG
PCHL ;NOTE: (DE) <- CFA+1
Incrementing W in NEXT by at least one was unavoidable.
Why?
; 8080 FIG-FORTH
NEXT LDAX B ;(W) <- ((IP))
INX B ;(IP) <- (IP)+2
MOV L,A
LDAX B
INX B
MOV H,A ;(HL) <- CFA
NEXT1 MOV E,M ;(PC) <- ((W))
INX H
MOV D,M
XCHG
PCHL ;NOTE: (DE) <- CFA+1
Incrementing W in NEXT by at least one was unavoidable.
It would have aided
portability to have W point to the same place in every FIG implementation.
dxforth <dxforth@gmail.com> writes:
On 18/05/2022 15:54, Anton Ertl wrote:
dxforth <dxforth@gmail.com> writes:
; 8080 FIG-FORTH
NEXT LDAX B ;(W) <- ((IP))
INX B ;(IP) <- (IP)+2
MOV L,A
LDAX B
INX B
MOV H,A ;(HL) <- CFA
NEXT1 MOV E,M ;(PC) <- ((W))
INX H
MOV D,M
XCHG
PCHL ;NOTE: (DE) <- CFA+1
Incrementing W in NEXT by at least one was unavoidable.
Why?
Do you know of an 8080 NEXT that's at least as fast that didn't?
I don't know much about the 8080, so I would be interested in an
explanation.
Looking at it again, I see
NEXT1 MOV E,M ;(PC) <- ((W))
INX H
MOV D,M
So is M another name for (HL)? And H is the low-order byte of HL (and
the CFAs never straddle 256-byte boundaries, which is also necessary
on the 6502). In that case it's clear why W is incremented by 1.
What does the XCHG do and what is it good for?
I assume that PCHL is a kind of indirect jump, but it would need the
value in DE. Given the name of PCHL and the comment at the end, I
suspect that XCHG exchanges DE and HL, so W is in DE at the end, and
the code address in HL.
- anton--
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
On 18/05/2022 15:54, Anton Ertl wrote:
dxforth <dxforth@gmail.com> writes:
; 8080 FIG-FORTH
NEXT LDAX B ;(W) <- ((IP))
INX B ;(IP) <- (IP)+2
MOV L,A
LDAX B
INX B
MOV H,A ;(HL) <- CFA
NEXT1 MOV E,M ;(PC) <- ((W))
INX H
MOV D,M
XCHG
PCHL ;NOTE: (DE) <- CFA+1
Incrementing W in NEXT by at least one was unavoidable.
Why?
Do you know of an 8080 NEXT that's at least as fast that didn't?
My guess is „it is”, still I'd like to become 100% sure.
Here's the „NEXT” of that mentioned fig-Forth:
NEXT: LODSW
MOV BX,AX
NEXT1: MOV DX,BX
INC DX
JMP [BX]
(BTW: anyone could tell me, how should I paste code here to avoid deformation?)
So if I'm correct DX works as Forth's „W” register here.
My question is: then why is it incremented at that moment? And actually it's just half-incremented, since we need cell-stepped incrementation, not by single byte.
My suspicion seems to be confirmed by DOCOL's code (and by similarly looking code of other „DO”-s):
DOCOL: INC DX
DEC BP
DEC BP
MOV [BP],SI
MOV SI,DX
JMP NEXT
From what I understand, incremention of „W” has been splitted into two stages. If I made this, I'd rather insert two INCs into „DOCOL”, leaving
original value of „W” untouched (if it may be needed anywhere; it does contain the address of currently processed word anyway).
Does that „split-action” have any merits behind it? Or is it just on the rule: „well, someone years ago made it this way, and then all the followers
copied that because it worked doing no harm”?
They were not familiar to the very powerful (?!) 8086 instruction set
DOCOL:
DEC BP }
DEC BP } push si on the returns stack
MOV [BP],SI }
MOV SI,[BX+2]
JMP NEXT
Saving the manipulation with reg DX.
But MOV SI,[BX+2] means „copy contents pointed by BX+2” rather than „copy BX+2 to SI”, correct? So it won't work here as replacement.
Anyway eliminated superfluous use of DX from NEXT, DOCOL, DOCON, DOVAR,
DOUSE and DODOE — everything replaced by BX manipulation only — and... it still
seems to work just fine. :)
Incrementing W in NEXT by at least one was unavoidable. It would have aided >> portability to have W point to the same place in every FIG implementation.
Thanks. I didn't work with 8080 assembly before; could you, please,
take a look did I properly „decode” your listing:
NEXT: LDAX B ;(W) <- ((IP)) // A := BC C@
INX B ;(IP) <- (IP)+2 // BC := BC + 1
MOV L,A // L := A
LDAX B // A := BC C@
INX B // BC := BC + 1
MOV H,A ;(HL) <- CFA // H := A
; IP uses BC, W uses HL
; So now W = (IP) and IP = former_IP + 2
NEXT1: MOV E,M ;(PC) <- ((W)) // E := HL C@
INX H // HL := HL + 1 (which means W := W + 1)
MOV D,M // D := HL C@ // X := (W)
XCHG // HL and DE pairs swap their contents (W turns into X and vice versa) PCHL ;NOTE: (DE) <- CFA+1 // JMP (HL) which means JMP (X)
So all this because 8080 has no command to do 16-bit transfer -- and sometime later
the translation of the code to x86 has been done „literally”, 1:1 -- no optimization at all?
On 18/05/2022 21:52, Zbig wrote:
So all this because 8080 has no command to do 16-bit transfer -- and sometime later
the translation of the code to x86 has been done „literally”, 1:1 -- no optimization at all?
That's understandable considering few would have owned an 8086 at that time.
Fig-Forth 8088/86 listing is dated MAR 1981. FIG had largely dropped support >for Fig-Forth by then, opting instead to be involved in the Standards process. >While FIG planned comprehensive revisions to several implementations, only >the 8080 was completed AFAIK.
The fig-Forth NEXT was not a 1:1 translation, though:
dxforth <dxforth@gmail.com> writes:
On 18/05/2022 21:52, Zbig wrote:
So all this because 8080 has no command to do 16-bit transfer -- and sometime later
the translation of the code to x86 has been done „literally”, 1:1 -- no optimization at all?
That's understandable considering few would have owned an 8086 at that time.
It's also not unusual: The story of how Microsoft ported Fortran-80
(and other products) to the 8086 is described in <https://retrocomputingforum.com/t/translation-of-8080-code-to-8086/1309>. The author concludes that the result made a disappointing product, and
in comment #6 relates that MS then bought a license of a third-party
Fortran, certainly a winning strategy for MS.
Makes me wonder how much of a benefit the ability to translate 8080 to
8086 assembly code really was. It led to a lot of software early on,
such as Fortran-96 and fig-Forth, but could not transcend the 64K
boundary (but early-on few had more RAM), and eventually that software
was replaced with something specifically written for the 8086, such as
F83 or the external product in the Fortran case (that compiler was
written in Pascal).
I guess the benefit was that software was available earlier, but if
anybody hoped they could save on proper 8086 development, they were disappointed, or their product was unlikely to survive.
...
Fig-Forth 8088/86 listing is dated MAR 1981. FIG had largely dropped support >>for Fig-Forth by then, opting instead to be involved in the Standards process.
While FIG planned comprehensive revisions to several implementations, only >>the 8080 was completed AFAIK.
Support? Revisions? Are these compatible with the teachings of Chuck
Moore?
...
Here's my go at a 1:1 translation according to the translation table:
NEXT LDAX B mov si, cx
mov al, [si]
INX B inc cx
MOV L,A mov bl, al
LDAX B mov si, cx
mov al, [si]
INX B inc cx
MOV H,A mov bh, al
NEXT1 MOV E,M mov dl, [bx]
INX H inc bx
MOV D,M mov dh, [bx]
XCHG xchg bx,dx
PCHL jmp bx
On 19/05/2022 15:42, Anton Ertl wrote:
Support? Revisions? Are these compatible with the teachings of Chuck
Moore?
One would need to ask the promoters of his 'teachings' :) ISTR Elizabeth >saying Chuck's second version of anything was much better than the first,
and if there were opportunity for a third, it was better again. Sounds
like most of us - no?
dxforth <dxforth@gmail.com> writes:
On 19/05/2022 15:42, Anton Ertl wrote:
Support? Revisions? Are these compatible with the teachings of Chuck
Moore?
One would need to ask the promoters of his 'teachings' :) ISTR Elizabeth >>saying Chuck's second version of anything was much better than the first, >>and if there were opportunity for a third, it was better again. Sounds >>like most of us - no?
My understanding is that his approach is to rewrite from scratch
rather than revise the existing code. Looking at the changes from his
Forth that most Forth systems are descended from to cmForth to
colorForth, these are not revisions.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 51:55:10 |
| Calls: | 6,712 |
| Calls today: | 5 |
| Files: | 12,243 |
| Messages: | 5,355,044 |
| Posted today: | 1 |