mgcaret/of816

Portable 32-bit Forth for the 65C816.

of816's Issues

Native FM/MOD incorrect results

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

C! And W! Don’t need indexed addressing.

This is a leftover from adapting my 8-bit code.

Nested loop in temporary definition causes exception -60 (FREE).

3 0 do i . loop 
0 1 2  OK
3 0 do 3 0 do i . j . loop loop
 Exception #-60 

Concerning immediacy in IEEE 1275-1994

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.

Build fails on recent ca65.

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.

text input number handling inconsistent with IEEE 1275-1994

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:

• Accept double numbers (trailed with .)
• Ignore , and . within input numbers

Signed comparisons involving minimum signed integer fail

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

MOVE problem

INCORRECT RESULT: T{ SEEBUF -> 12 12 34 }T OK
INCORRECT RESULT: T{ SEEBUF -> 12 34 34 }T OK

weird "magic" with no_headerless 0 (or macros, or linker?)

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

Probably perfectly working code with no_headerless 1

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

"good", but probably also invalid code with no_headerless 0

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

"bad" and unusable code with no_headerless 0

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

C@ should perform an 8-bit access

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.