pzembrod / cc64 Goto Github PK

Currently all expression evaluation happens with 16 bit width: All additions, shifts, logic operators, all happen with 16 bit (lobyte in A, hibyte in X). The same goes for all hardware stack pushes during expression evaluation: Always 2 pushes: pha:txa:pha.
It would be nice if the calculations could be limited to 8 bits where those are sufficient.
v-assembler.fth already has the basic mechanism needed for this in the form of the "sized" .lda.s etc. pseudo-operations, where the template contains w: ;w and b: ;b sequence snippets that are only instantiated for word or byte size operations, respectively.
The biggest challenge would be to keep track of the size of each hardware stack push, but since the parser keeps a compile time stack of object types (incl. size) in sync with the runtime hardware stack, the basis for this is also already in place.
Still, it would be a non-negligible effort, and might easily cost a few hundred bytes in compiler size, so that should be checked beforehand, esp. wrt. the chronically tight memory at compiler compile time on the X16.

Due to a build script bug the rt-c64-0801.h file looked like this:

#pragma cc64 0xfd 0xfb 0x801 0x824 0x9ce 0xa000 0xa000 tmp/rt-c64-0801

Namely, a tmp/ in the library name param.
When running tests with that, compiling this line with cc64 led to a CPU jam in VICE.
This doesn't seem to have anything to do with VICE not finding a file but is more likely either due to a parse error in the param, or due to a buffer overflow.

Probably something around devices. Initially seems to want to load from device 255, and doesn't load any files at all.
Also building is tricky; memory is tight, and it seems that the save in the build-cc64pe.fth script doesn't really free the memory of transient words and the transient assembler.

Remains to be verified via a test, but looking at

| : atom ( -- obj )
#number# comes-a?
IF do-numatom exit THEN
#id# comes-a?
IF do-idatom exit THEN
#string# comes-a?
IF drop compile$
do-stringatom exit THEN
." a value" expected error
0 do-numatom ;

in parser.fth, it seems I have forgotten to implement character literals.

This should be made platform-dependent with (64 C) and (16 C), doing something similar and suitable on the C16.

The same fix to provide for an existing savesystem needs to be applied to peddi_src.d64/fth block 10 as already was done for standalone cc64v05.

The backup file peddi creates is prefixed with / - that doesn't work well, of course, with file-system backed virtual emulated drives; that character should be replaced by something else - ~ maybe.

In
| : std-arguments ( -- )
assign put-std-argument
BEGIN ascii , #char# comes? WHILE
assign drop-std-argument REPEAT ;

the intended behaviour was most likely that only the first argument to a stdfunction gets used, any further arguments should be dropped. However, there seems to be a .pha missing somewhere (probably after the WHILE) to match the .pla in drop-std-argument:

| : put-std-argument ( obj -- )
value non-constant 2drop ;

| : drop-std-argument ( obj -- )
value non-constant 2drop .pla ;

In peddi block 37 there is a derror? usage with a fix for drive ( dev 8 - (drv ! ) that shouldn't be there; it should be removed and replaced by an i/o-status? check plus possibly a call to dos aka print error channel.
But derror? is focused on ultraForth's drv device number not cc64's device variable.

E.g. function too long error.
Expected: compiler returns to the shell with an ok
Actual: no cursor, and before that a CPU jam in the emulator

\ *** Block No. 81, Hexblock 51
make scratchfiles ( -- )
." scratching temporary files" cr
dev 15 busout
" s0:%%*" count bustype busoff ;

Scratching %%* doesn't seem to work with Linux file system backed virtual 1541 drives in the Vice emulator; only %%code gets scratched, old %%init files accumulate.
Easiest fix: 2 separate scratch statements for %%code and %%init.

When activating the "Optimize code, inline standard funtions" (-Os) or the "Optimize code, inline more code" (-Oi) option, if a C source code has (in sequence) a direct write statement and a direct read statement on the same RAM memory location, the reading step is omitted.

The problem arises if the memory is accessed using the address directly. It does not occur if the address to read and write from is stored in a (temporary) pointer variable, or if the optimization is disabled.

Currently, the only workaround to avoid allocating an additional variable is to assign a value of 0 to the (destination) memory location: this prevents the optimizer from exploiting the value just written.

However, I believe there should be a way to indicate that (specific?) memory locations can be "volatile" so that the optimizer cannot make any assumptions about the reusability of their value.

Example:

unsigned char port;
[...]
(*(unsigned char*)0xff08) = 0x04;
port = (*(unsigned char*)0xff08);        `

This is the correct assembly output (without -Osir optimizations):

00042Cr 1               ;
00042Cr 1               ; (*(unsigned char*)0xff08) = 0x04;
00042Cr 1               ;
00042Cr 1  A2 00        	ldx     #$00
00042Er 1  A9 04        	lda     #$04
000430r 1  8D 08 FF     	sta     $FF08
000433r 1               ;
000433r 1               ; port = (*(unsigned char*)0xff08);
000433r 1               ;
000433r 1  A2 00        	ldx     #$00
000435r 1  AD 08 FF     	lda     $FF08 ; <--- this is the step missed!
000438r 1  8D rr rr     	sta     L0117
00043Br 1               ;

This is the (wrong) assembly output:

000281r 1               ; (*(unsigned char*)0xff08) = 0x04;
000281r 1               ;
000281r 1  A9 04        	lda     #$04
000283r 1  8D 08 FF     L0158:	sta     $FF08
000286r 1               ;
000286r 1               ; port = (*(unsigned char*)0xff08);
000286r 1               ;
000286r 1  8D rr rr     	sta     L0118
000289r 1               ;

This is the workaround:

000289r 1               ; (*(unsigned char*)0xff08) = 0x04;
000289r 1               ;
000289r 1  8D 08 FF     	sta     $FF08
00028Cr 1               ;
00028Cr 1               ; port = 0;
00028Cr 1               ;
00028Cr 1  8C rr rr     	sty     L0118
00028Fr 1               ;
00028Fr 1               ; port = (*(unsigned char*)0xff08);
00028Fr 1               ;
00028Fr 1  AD 08 FF     	lda     $FF08 ; <--- this is the step needed
000292r 1  8D rr rr     	sta     L0118

Command line used to compile:

cl65 -T -l obj/plus4/midres_plus4.asm -t plus4 -c -W -const-comparison -Osir -Cl -D__CBM__ -o obj/plus4/midres_plus4.o obj/plus4/midres_plus4.c

In cc64src2 Block No. 91, there seems to be a >r without a matching r> or rdrop

| : adjust-prototype
( obj desc type -- obj desc )
2 pick compare-types >r
protos2resolve BEGIN dup
@ dup 0= compiler ?fatal
2+ @ r@ - WHILE @ REPEAT
hook-out 2 pick over 2+ !
dup 4 + @ sort-in hook-into ;

Repro:
Remove the shift-return (\x8d) at the beginning of line 21 of editfile.keybuf, and the editfile test will crash peddi.
I'm not clear what the problem exactly is, but it seems to be connected to long lines or horizontal scrolling to the end of such lines, or vertical srolling when horizontally scrolled to the end of a long line. The crash seems to triggered by the kill-line command (ctrl-P, \x10) in line 25 of editfile.keybuf.

Possibly related: When one scrolls down to the end of the test file editfile.before (or widelines.before), then the screen displays a line of tilde characters at some point, which disappears again when one scrolls to the top again. Not sure if this is just a display bug or if it potentially affects the file content as well. It doesn't seem to affect the file content in the above scenario, but it might if one makes edits e.g. during the bad display state.

Better testing would be desirable for this, so far I don't have a good way of verifying the screen display in an automated test.

Currently the words >inittype and (init$ in parser.fth:800-810 encode a rule that forbids array initializers for local non-static arrays.
Reason for my decision for this way back was probably this: To implement array initializers for stack local variables would require a memcopy operation whereas static arrays can be initialized in the global initial static var initialization; I probably wanted to avoid the need for the memcopy operation.
To be decided how this should be handled going forward, i.e. whether initializers of stack local arrays should be supported.

The v05/c64files dir should contain all files needed to use cc64 on a C64.