mgcaret / of816 Goto Github PK
View Code? Open in Web Editor NEWPortable 32-bit Forth for the 65C816.
License: Other
Portable 32-bit Forth for the 65C816.
License: Other
INCORRECT RESULT: T{ MIN-INT MAX-INT MAX -> MAX-INT }T OK
INCORRECT RESULT: T{ 0 MIN-INT MAX -> 0 }T OK
INCORRECT RESULT: T{ MAX-INT MIN-INT MAX -> MAX-INT }T OK
INCORRECT RESULT: T{ MIN-INT MAX-INT MIN -> MIN-INT }T OK
INCORRECT RESULT: T{ 0 MIN-INT MIN -> MIN-INT }T OK
INCORRECT RESULT: T{ MAX-INT MIN-INT MIN -> MIN-INT }T OK
INCORRECT RESULT: T{ MIN-INT MAX-INT < -> <TRUE> }T OK
INCORRECT RESULT: T{ 0 MIN-INT < -> <FALSE> }T OK
INCORRECT RESULT: T{ MAX-INT MIN-INT < -> <FALSE> }T OK
INCORRECT RESULT: T{ MIN-INT MAX-INT > -> <FALSE> }T OK
INCORRECT RESULT: T{ 0 MIN-INT > -> <TRUE> }T OK
INCORRECT RESULT: T{ MAX-INT MIN-INT > -> <TRUE> }T OK
INCORRECT RESULT: t{ min-int max-int >= -> <false> }t OK
INCORRECT RESULT: t{ max-int min-int >= -> <true> }t OK
INCORRECT RESULT: T{ 1 S>D -1 FM/MOD -> 0 -1 }T OK
INCORRECT RESULT: T{ 2 S>D -1 FM/MOD -> 0 -2 }T OK
INCORRECT RESULT: T{ 7 S>D -3 FM/MOD -> -2 -3 }T OK
This is a leftover from adapting my 8-bit code.
Hi,
recently I made some observations about generated code - I'm rather pretty sure, that I found some kind of bug, but I'm not able to fully understood it nature.
Some background: some months ago I started port for C256 (thanks for referencing to my project). After putting whole thing into usable shape (at least I was able to transfer files by my xmodem version, included in fcode/xmodem.fs) I got break and few days ago I returned to next step - an ANSI terminal support.
And then magic begins. Even very simple changes leads to "instabilities" - resets, hangs, etc. on real hw. Unfortunately official emulator still has problems with code and my own project it works fine (or I made incorrect tests), so I was forced to stick with real machine.
I made all tests, to be sure that problems doesn't come from C256's construction and kernel (overlapping rom areas, clearing during reset routines etc). Nope. I made also multiple tests and checks about memory locations of stacks: os, return and parameters. Still nothing.
During test I realize, that instability appears when size platform-lib.s grows. So - thoughts about page crossings or something similar come to my mind. I replace all new code by multiple "NOP" and, after several compilations, I got "a good" and "bad" (with one more NOP inside) code. Then I started comparing binaries (I made something like that before, during work on byte-to-byte exact conversion of LiaraForth to 64tass), so I was brave ;)
To make a long story shorter: I found some irregularities in code and I was pretty sure that I found bug in linker or assembler (I tested even latest version from repo, BTW) but today I found something that leads me to conclusion that clue is in macro expansion or ca65 or in linker itself: at this moment I'm not able to judge. From my POV looks like that code compiled with no_headerless 0 was invalid and "good" and "bad" binaries was only a matter of luck.
As reminder: my version usess memory at 0x3a:0000
Listing file from ca65 -l forth.lst
with placeholder values manually replaced by data from binaries
As You can see there looks like perfectly valid code (and it works!)
"really good" with no_headerless 1
00 00 00 00 dword XYZZY,"XYZZY",F_IMMED
85 58 59 5a
5a 59 a0
22 7b 01 3a ENTER
7c 0e 3a 00 .dword FORTH
b9 01 3a 00 EXIT
00 00 00 00 hword WLNUM,"WL#
83 57 4c 23
20
22 7b 01 3a ENTER
c3 0e 3a 00 .dword dORDER
b4 21 3a 00 .dword SWAP
...and ca65 -v -v -v -v
output looks like (linker debug, in all cases, shows proper addresses):
"really good" with no_headerless 1
Literal: EA EA EA EA EA EA EA EA EA EA EA / my placeholder at end of platform-libs.s
00 00 00 00 / dword macro
85 58 59 5A
5A 59 A0
22 Expression (3): SYM( SEC $0136 +) / enter
Expression (4): SYM( SEC $0E37 +) / dword forth
Expression (4): SYM( SEC $0175 +) $0001 - / exit
Literal: 00 00 00 00 / hword (dword) macro WLNUM
83 57 4C 23
20
22 Expression (3): SYM( SEC $0136 +) / enter
Expression (4): SYM( SEC $0E7E +) / dword dorder
Expression (4): SYM( SEC $216F +) / dword swap
Take a look, please at hword WLNUM and ENTER macro result
00 00 00 00 dword XYZZY,"XYZZY",F_IMMED
85 58 59 5A
5A 59 A0
22 7B 01 3A ENTER
74 0E 3A 00 .dword FORTH
B9 01 3A 00 EXIT
80 20 hword WLNUM,"WL#
22 7B 00 01 ENTER !!! (should be 22 7b 01 3a)?
3a a6 0e 3a .dword dORDER
00 72 20 3a .dword SWAP
...
and ca65 verbose:
Literal: EA EA EA EA EA EA EA EA EA EA / my placeholder at end of platform-libs.s
00 00 00 00 / dword macro
85 58 59 5A
5A 59 A0
22 Expression (3): SYM( SEC $0136 +) / enter
Expression (4): SYM( SEC $0E2F +) / dword forth
Expression (4): SYM( SEC $0175 +) $0001 - / exit
Literal: 80 20 / hword macro
22 Expression (3): SYM( SEC $0136 +) / enter
Expression (4): SYM( SEC $0E61 +) / dword dorder
Expression (4): SYM( SEC $202D +) / dword swap
The difference is in single NOP at and of platform-lib.s, so single-byte differences are expected - but take a look at ENTER macro in WLNUM word - there is also byte swap (00 7b 01) in comparision to previous, shorter by one byte, code: (7b 00 01)
00 00 00 00 dword XYZZY,"XYZZY",F_IMMED
85 58 59 5A
5A 59 A0
22 7B 01 3A ENTER
75 0E 3A 00 .dword FORTH
B9 01 3A 00 EXIT
80 20 hword WLNUM,"WL#
22 00 7B 01 ENTER !!! as above + 00 7b 01 in place of 7b 00 01
3a a7 0e 3a .dword dORDER
00 73 20 3a .dword SWAP
compare that with copy from previous point - there is also a byte swap, that is a really mystery for me:
; from compilation with *lib.s code shorter by one byte
80 20 hword WLNUM,"WL#
22 7B 00 01 ENTER !!! (should be 22 7b 01 3a)?
3a a6 0e 3a .dword dORDER
00 72 20 3a .dword SWAP
ca65 output section is the same:
Literal: EA EA EA EA EA EA EA EA EA EA EA / my placeholder at end of platform-libs.s
00 00 00 00
85 58 59 5A
5A 59 A0
22 Expression (3): SYM( SEC $0136 +) / enter
Expression (4): SYM( SEC $0E30 +) / dword forth
Expression (4): SYM( SEC $0175 +) $0001 - / exit
Literal: 80 20
22 Expression (3): SYM( SEC $0136 +) / enter
Expression (4): SYM( SEC $0E62 +) / dword dorder
Expression (4): SYM( SEC $202E +) / dword swap
I move here the discussion from ForthHub:
@mgcaret wrote:
By the way,
]
is an ordinary word (not immediate), but you seem define it as immediate.I don't seem to, I do. It even says why in the comments. OF816 is implemented follwing IEEE 1275-1994 (AKA "Open Firmware) and
]
is listed in "7.3.9.2.2 Immediate words," regardless of what any other standard might say.
It looks like the section 7.3.9.2.2 lists not immediate words, but the words that are connected to the immediacy mechanism in some way. For example, state
and compile,
are not immediate words by any means.
Also, have a look to the code A (in A.1.2.3 Type codes field):
A ANS Forth word. In most cases, the description body for such words consists only of a one-line brief
description. The full specification is given by ANSI X3.215-1994
This code is specified for the word ]
, and it means that the full specification for this word should be taken from the Forth-94 standard ("ANS Forth", ANSI X3.215-1994).
So, immediacy should be corrected for some words in your system, I think.
The standard states:
In accordance with ANSI X3.215-1994, an Open Firmware command interpreter treats numbers that end with a period (e.g., 123456.) as double numbers. Unlike ANSI X3.215-1994, which does not specify what happens with embedded periods, an Open Firmware command interpreter ignores “.” or “,” at other positions within numbers (e.g., 120.0000). Such embedded periods or commas may be used to make it easier for humans to read the numbers, but have no significance to the command interpreter. By convention, such periods or commas usually appear four digits from the right.
OF816 does not:
3 0 do i . loop
0 1 2 OK
3 0 do 3 0 do i . j . loop loop
Exception #-60
INCORRECT RESULT: T{ SEEBUF -> 12 12 34 }T OK
INCORRECT RESULT: T{ SEEBUF -> 12 34 34 }T OK
The code currently implements a 16-bit access and ands the value with 00FF. It should do an 8-but access to avoid hardware side effects.
ca65 now enforces constant-ness on strings used in .include inside macros, so it breaks the platform_include macro.
This appears to be caused by cc65/cc65#1477
Will have to re-think the entire platform builds process now.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.