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.
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.
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
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.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).
Oops, right, I wasn't really looking.
@ersmith said:
@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_,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_
@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 long pa<<19 | cogdatbuf<<9 // register PA for ALTI result 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:
objtest.spin2:
Newer 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:
bad:
that 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.
EDIT2: 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.
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:
Found 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.