flexspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler

pik33 · 2024-12-10 10:01

There is a simple test code that shows the difference:

test.bas:

dim test2 as class using "objtest.spin2"

test2.start
print varptr(test2.var2)

objtest.spin2:

var

long var1
long var2[64]

pub start

var1:=@var2
word[var2+17*12+4]:=8            
word[var2+17*12+6]:=16

Newer compilers print 0 while older print a non zero value

pik33 · 2024-12-10 10:21

Newer compiler returns value of var2[0] instead of address ov var2.. Add var2[0]:=$deadbeef to objtest.spin2 and you got "deadbeef' as a result of test.bas.

There is a difference in list files:

good:

00798     C7 AA 01 F6 |     mov local01, objptr
0079c     04 AA 05 F1 |     add local01, #4
007a0     00 A0 05 F6 |     mov arg01, #0
007a4     00 AC 05 F6 |     mov local02, #0
007a8     44 0A B0 FD |     call    #__system___gettxfunc

bad:

00798     C7 A0 01 F6 |     mov arg01, objptr
0079c     04 A0 05 F1 |     add arg01, #4
007a0     D0 AA 01 FB |     rdlong  local01, arg01
007a4     00 A0 05 F6 |     mov arg01, #0
007a8     00 AC 05 F6 |     mov local02, #0
007ac     44 0A B0 FD |     call    #__system___gettxfunc

that directed me to test if the program returns a value instead of the pointer.

pik33 · 2024-12-10 10:39

Yet another test: the C compiler works as expected even in the newest compiler verson. The C test program

#include <stdio.h>
struct __using("objtest.spin2") test2;

void main(){
        test2.start();
        printf ("%08x\n",&test2.var2);
        printf ("%08x\n",test2.var2[0]);
        }

returns good values using Version 7.0.0-beta2-v7.0.0-beta2-10-g7bc1389e Compiled on: Dec 8 2024

Only the Basic's varptr is affected.

Trying print varptr(test2.var2(0)) - that doesn't help and still return 'deadbeef'

ersmith · 2024-12-11 21:46

Thank you for the simple example, @pik33 . The root cause of the problem was a change to the Spin2 language to make references "transparent". This affected an internal function used to implement the BASIC varptr operation. It should be fixed now in the current github repo.

Rayman · 2024-12-11 22:34

@ersmith Just noticed something odd when doing "Identify Serial Ports"...

When you do the similar "Identify Hardware" in Prop Tool, seems like the P2 reboots when done identifying.

The flexprop version seems to put the chip in some unknown state (at least to me).
Would it be better to have it reboot the P2 when done identifying?

ersmith · 2024-12-12 10:29

@Rayman I think "Identify Serial Ports" fails if there's anything in the flash of the attached P2s. I should probably just remove it.

pik33 · 2024-12-12 19:39

@ersmith said:
Thank you for the simple example, @pik33 . The root cause of the problem was a change to the Spin2 language to make references "transparent". This affected an internal function used to implement the BASIC varptr operation. It should be fixed now in the current github repo.

The newest version works and compiles the interpreter.

evanh · 2024-12-14 07:05

fwrite() is broken in newest master. It reports zero written data but it does write one block full of 0x9e repeating. errno is zero.

EDIT: Err, no, it does report one block written.
EDIT2: Ah-ha! Just had a squiz at fwrite() in include/libc/stdio/fwrite.c and found the bug. Fixed with this:

    size_t size = n;

    if (elemSize != 1)
        size *= elemSize;

And I see fread() is the same ... yep, all's good again.

ersmith · 2024-12-14 15:35

Thanks, @evanh

evanh · 2024-12-15 07:03

Righty-ho, the 4-bit SD mode SD card driver is ready for inclusion.

I've zipped up the driver (sdsd.cc) and a speed tester program and my own instructions for installing it into the block driver tree. I've also included a modified version of newest fatfs_vfs.c that matches my install instructions.

PS: I haven't written any ioctl() programming instructions. There is hints in the tester's mounting function. At this stage the control codes (#70..72) are pulled out of thin air and only defined in the driver itself. I don't know if there is preferred numbering protocol or not.

In future I'm thinking TRIMming could be offered via ioctl() as well.

Rayman · 2024-12-15 21:43

Can exFat be enabled in FatFs now?

Seems that needed 64-bit integers last time this was asked, but seems we have these now?

Wuerfel_21 · 2024-12-15 22:11

@Rayman said:
Can exFat be enabled in FatFs now?

Seems that needed 64-bit integers last time this was asked, but seems we have these now?

ShouldWork^TM. Currently can't be set with external define though, need to edit ffconf.h to try it.

Rayman · 2024-12-15 22:22

It would be nice to have that virtually unlimited file size...

evanh · 2024-12-22 04:21

Eric,
On the Fcache allocation issue again, how about allowing adding of RES directives to specify trailing cogRAM needs? That would fix it for what I'm wanting.

And doing this would also solve a separate workaround where I've been using a bunch of enums to give labels to each of the preset parameter registers. They could be individual res 1 allocations instead. Much cleaner.

PS: Amusingly, the C compiler doesn't complain when I have RES directives. It doesn't work either.

EDIT: Ah, looking at the generated .lst file, I see RES is copied like a DAT LONG would be. That would need fixed along with whatever is causing the crash.

00a68     97 1A 48 FB |     callpa  #(@LR__0040-@LR__0030)>>2,fcache_load_ptr_
00a6c                 | LR__0030
00a6c 000             |     org 0
00a6c 000 F0 1D 80 FE |     loc pa, #@_dat_ + 4
00a70 001 28 10 64 FD |     setq    #8
00a74 002 F6 1B 00 FB |     rdlong  LR__0031, pa
00a78 003 0D AA 01 F6 |     mov local01, LR__0031
00a7c 004 0E AC 01 F6 |     mov local02, LR__0032
00a80 005 0F AE 01 F6 |     mov local03, LR__0033
00a84 006 10 B0 01 F6 |     mov local04, LR__0034
00a88 007 11 B2 01 F6 |     mov local05, LR__0035
00a8c 008 12 B4 01 F6 |     mov local06, LR__0036
00a90 009 13 B6 01 F6 |     mov local07, LR__0037
00a94 00a 14 B8 01 F6 |     mov local08, LR__0038
00a98 00b 15 BA 01 F6 |     mov local09, LR__0039
00a9c 00c 24 00 90 FD |     jmp #LR__0040
00aa0 00d             | LR__0031
00aa0 00d             |     res 1
00aa0 00e             | LR__0032
00aa0 00e             |     res 1
00aa0 00f             | LR__0033
00aa0 00f             |     res 1
00aa0 010             | LR__0034
00aa0 010             |     res 1
00aa0 011             | LR__0035
00aa0 011             |     res 1
00aa0 012             | LR__0036
00aa0 012             |     res 1
00aa0 013             | LR__0037
00aa0 013             |     res 1
00aa0 014             | LR__0038
00aa0 014             |     res 1
00aa0 015             | LR__0039
00aa0 015             |     res 1
00aa0 016             |     fit 128
00aa0 016             | LR__0040
00aa0                 |     orgh

EDIT2: Attached a test program.

pik33 · 2024-12-23 11:38

Some glitches after a year gap in developing the player.

D:/Programowanie/P2-retromachine-2/Propeller/P2P16/player33.bas:1605: error: Inline assembly too large to fit in fcache

Did the fcache shrink? The player compiled earlier...

evanh · 2024-12-23 11:44

Yes, the default was reduced to fit, I think, the growing, but optional, byte-code VM. Compile using --fcache=256 to get it larger when compiling for native.

PS: It can go bigger than 256 but I'd hope you're not using more than that.

pik33 · 2024-12-23 12:17

I managed to strip one long from the code (and then it fit) but this --fcache=256 will go to the command line. I don't use bytecode (yet?)

Edit: that was not a good idea. However, fcache=192 did the trick. fcache=256 seems to be too big and generated errors - code too big to fit in the cog

evanh · 2024-12-23 12:44

I can reserve up to 360 when compiling the SD card speed tester. I guess something else must also consume cogRAM then.

pik33 · 2024-12-23 13:28

The program - a multiformat media player - is big, including an mp3 decoder. and several other objects.

dim v as class using "hg008.spin2"
dim rm as class using "usbnew.spin2"
dim tracker as class using "trackerplayer.spin2"
dim paula as class using "audio093b-8-sc.spin2"
dim sid as class using "sidcog8.spin2"
dim psram as class using "psram.spin2"
dim spc as class using "spccog.spin2"
dim a6502 as class using "a6502-1.spin2"
dim mp3 as class using "mp3.c"

I don't know what needs the space in the cog. My code that didn't fit in the has (about) 128 longs in it. Maybe the standard size is now 128

evanh · 2024-12-23 13:47

Reading the basic.md file, it looks like there is four ways to compile the Basic source code:

 A predefined symbol is also generated for type of output being created:
-------------------------|-------------
__OUTPUT_ASM__ | if PASM code is being generated
__OUTPUT_BYTECODE__ | if bytecode is being generated
__OUTPUT_C__ | if C code is being generated
__OUTPUT_CPP__ | if C++ code is being generated

What's the chances you're compiling for byte-code?

pik33 · 2024-12-23 15:09

0

I tried the bytecode, it is way too slow for this program to run.

flexspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler

Comments