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
0079c04 AA 05 F1 | add local01, #4007a000 A005 F6 | mov arg01, #0007a400 AC 05 F6 | mov local02, #0007a8440A B0 FD | call #__system___gettxfunc
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.
@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.
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:
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.
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.
00a68971A 48 FB | callpa #(@LR__0040-@LR__0030)>>2,fcache_load_ptr_
00a6c | LR__003000a6c000 | org 000a6c000 F01D 80 FE | loc pa, #@_dat_ + 400a70001281064 FD | setq #800a74002 F61B 00 FB | rdlong LR__0031, pa
00a780030D AA 01 F6 | mov local01, LR__003100a7c0040E AC 01 F6 | mov local02, LR__003200a800050F AE 01 F6 | mov local03, LR__003300a8400610 B001 F6 | mov local04, LR__003400a8800711 B201 F6 | mov local05, LR__003500a8c00812 B401 F6 | mov local06, LR__003600a9000913 B601 F6 | mov local07, LR__003700a9400a 14 B801 F6 | mov local08, LR__003800a9800b 15 BA 01 F6 | mov local09, LR__003900a9c00c 240090 FD | jmp #LR__004000aa000d | LR__003100aa000d | res 100aa000e | LR__003200aa000e | res 100aa000f | LR__003300aa000f | res 100aa0010 | LR__003400aa0010 | res 100aa0011 | LR__003500aa0011 | res 100aa0012 | LR__003600aa0012 | res 100aa0013 | LR__003700aa0013 | res 100aa0014 | LR__003800aa0014 | res 100aa0015 | LR__003900aa0015 | res 100aa0016 | fit 12800aa0016 | LR__004000aa0 | orgh
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.
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
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?
@evanh said:
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.
I think it should be possible to use this without having to make any changes to the flexspin include tree, by using the _vfs_open_fat_handle() function and providing a block driver open function that exports a vfs_file_t *.
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.
We don't really have any standard yet for ioctls. I think the Linux kernel reserves some bits in the ioctl command to specify the kind of device that it applies to, maybe we could do something similar.
@evanh said:
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.
I think that should work now.
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.
No, although I can see why you thought that: the fcache load call uses @ addresses (HUB RAM) rather than COG addresses to calculate the size of the data to load. RES doesn't occupy any HUB space, so this actually all works out (as long as the RES all appear at the end).
@evanh said:
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.
No, although I can see why you thought that: the fcache load call uses @ addresses (HUB RAM) rather than COG addresses to calculate the size of the data to load. RES doesn't occupy any HUB space, so this actually all works out (as long as the RES all appear at the end).
@evanh said:
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.
I think that should work now.
No change. Looks like RES space is messing with Fcache's ALTD placement of the RET instruction. Might be time to throw away that mechanism of branching to a common RET.
FCACHE_LOAD_
mov fcache_tmpb_,ptrbpopptrbaltdpa,ret_instr_
mov0-0, ret_instr_
setqpardlong$0, ptrb++
pushptrbmovptrb,fcache_tmpb_
jmp #\$0' jmp to cache
ret_instr_
_ret_cmpinb,#0
fcache_tmpb_
long0
fcache_load_ptr_
long FCACHE_LOAD_
@evanh said:
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.
I think it should be possible to use this without having to make any changes to the flexspin include tree, by using the _vfs_open_fat_handle() function and providing a block driver open function that exports a vfs_file_t *.
Yeah, nice, it worked. I did four changes:
Moved the driver file out into the user source directory. EDIT: Now in a subdirectory blockdrivers.
Moved the driver opening function, _sdsd_open(), out to the user program. Since it references the driver file I don't suppose this can be placed in the driver itself? EDIT: Moved to a new file in the subdirectory.
Changed that function's driver reference path from struct __using("filesys/block/sdsd.cc") *SDSD; to struct __using("sdsd.cc") *SDSD;. EDIT: Now struct __using("blockdrivers/sdsd.cc") *SDSD;
And changed one line in the driver: #include "../fatfs/diskio.h" becomes #include <filesys/fatfs/diskio.h>
EDIT: Made it feel cleaner by putting the driver in its own directory along with a new file sdsd_vfs.c just for the driver opening function. The user program now just has to include the new file before calling _sdsd_open().
@evanh There was an optimizer issue which caused everything to fall down if there were RET statements inside inline assembly. I think that's fixed now in github; at least, I can compile a simple test program OK. If all else fails, you can insert a long $fd64002d as a RET instruction but that shouldn't be necessary.
Working so far. But I've hit a niggle that is probably something Chip needs to sort out - I now want to insert register symbol references into dat values at compile time. Currently I get error: data item is not constant
eg:
altireg longpa<<19 | cogdatbuf<<9 // register PA for ALTIresult substitution, and CRC buffer address
@ersmith said:
at least, I can compile a simple test program OK.
Found something weird. In one of my more complex routines, if I use a _RET_ modifier, irrespective of any following RET instruction, it looks to be screwing up an unrelated variable. And probably worse, because it crashes. The variables to registers mappings must be messed up. Won't be easy to replicate I suspect, it didn't happen on first routine I converted.
I note that all _RET_s get auto-converted to separate RET instructions anyway. So, to be safe, I've eliminated all _RET_ modifiers for now.
Comments
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]:=16Newer compilers print 0 while older print a non zero value
Newer compiler returns value of var2[0] instead of address ov var2.. Add
var2[0]:=$deadbeefto 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___gettxfuncbad:
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___gettxfuncthat directed me to test if the program returns a value instead of the pointer.
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 2024Only the Basic's varptr is affected.
Trying
print varptr(test2.var2(0))- that doesn't help and still return 'deadbeef'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
varptroperation. It should be fixed now in the current github repo.@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?
@Rayman I think "Identify Serial Ports" fails if there's anything in the flash of the attached P2s. I should probably just remove it.
The newest version works and compiles the interpreter.
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.cand 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.
Thanks, @evanh
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 newestfatfs_vfs.cthat 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.
Can exFat be enabled in FatFs now?
Seems that needed 64-bit integers last time this was asked, but seems we have these now?
ShouldWorkTM. Currently can't be set with external define though, need to edit ffconf.h to try it.
It would be nice to have that virtually unlimited file size...
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 1allocations 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 | orghEDIT2: Attached a test program.
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 fcacheDid the fcache shrink? The player compiled earlier...
Yes, the default was reduced to fit, I think, the growing, but optional, byte-code VM. Compile using
--fcache=256to 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.
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
I can reserve up to 360 when compiling the SD card speed tester. I guess something else must also consume cogRAM then.
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
Reading the
basic.mdfile, it looks like there is four ways to compile the Basic source code:What's the chances you're compiling for byte-code?
0
I tried the bytecode, it is way too slow for this program to run.
I think it should be possible to use this without having to make any changes to the flexspin include tree, by using the
_vfs_open_fat_handle()function and providing a block driver open function that exports avfs_file_t *.We don't really have any standard yet for ioctls. I think the Linux kernel reserves some bits in the ioctl command to specify the kind of device that it applies to, maybe we could do something similar.
I think that should work now.
No, although I can see why you thought that: the fcache load call uses
@addresses (HUB RAM) rather than COG addresses to calculate the size of the data to load. RES doesn't occupy any HUB space, so this actually all works out (as long as the RES all appear at the end).Oops, right, I wasn't really looking.
No change.
Looks like RES space is messing with Fcache's ALTD placement of the RET instruction. Might be time to throw away that mechanism of branching to a common RET.
FCACHE_LOAD_ mov fcache_tmpb_,ptrb pop ptrb altd pa,ret_instr_ mov 0-0, ret_instr_ setq pa rdlong $0, ptrb++ push ptrb mov ptrb,fcache_tmpb_ jmp #\$0 ' jmp to cache ret_instr_ _ret_ cmp inb,#0 fcache_tmpb_ long 0 fcache_load_ptr_ long FCACHE_LOAD_The final RET is needed so that code that doesn't explicitly return returns. You should be able to put a manual ret...
Yeah, nice, it worked. I did four changes:
blockdrivers.struct __using("filesys/block/sdsd.cc") *SDSD;tostruct __using("sdsd.cc") *SDSD;. EDIT: Nowstruct __using("blockdrivers/sdsd.cc") *SDSD;#include "../fatfs/diskio.h"becomes#include <filesys/fatfs/diskio.h>EDIT: Made it feel cleaner by putting the driver in its own directory along with a new file
sdsd_vfs.cjust for the driver opening function. The user program now just has to include the new file before calling _sdsd_open().Those all get replaced with branches to that final RET.
@evanh There was an optimizer issue which caused everything to fall down if there were
but that shouldn't be necessary.
RETstatements inside inline assembly. I think that's fixed now in github; at least, I can compile a simple test program OK. If all else fails, you can insert along $fd64002das a RET instructioncool, I see a lot of changes in master branch ...
Working so far. But I've hit a niggle that is probably something Chip needs to sort out - I now want to insert register symbol references into dat values at compile time. Currently I get
error: data item is not constanteg:
altireg long pa<<19 | cogdatbuf<<9 // register PA for ALTI result substitution, and CRC buffer addressFound something weird. In one of my more complex routines, if I use a
_RET_modifier, irrespective of any followingRETinstruction, it looks to be screwing up an unrelated variable. And probably worse, because it crashes. The variables to registers mappings must be messed up. Won't be easy to replicate I suspect, it didn't happen on first routine I converted.I note that all
_RET_s get auto-converted to separate RET instructions anyway. So, to be safe, I've eliminated all_RET_modifiers for now.