@"Christof Eb." said:
Hi,
does FlexProp C support raw literals?
No. That's a feature from the C++11 standard, which is way beyond what FlexC supports.
You'll have to turn the multi-line text into ordinary text with embedded new lines; something
like:
const char boot[] =
"some text\n"
"some more text\n"
"yet more text\n"
;
That is, put a " at the beginning of each line and a \n" at the end of the line.
This works because C will automatically merge adjacent strings, so "hello " "world" becomes "hello world".
Thanks for the reply!
Unfortunately this seems to be one of the smaller problems. I now have found a && with only one operand, which has to be a "move" thingy. And also something does not work with a struct or union. I will have to give up this port as I do not understand too much of the intentions....
Seems like should be relatively easy since Spin2 has it already with "file"?
#embed goes way beyond file; because #embed is a preprocessor directive, it can appear anywhere in the source, and it appears it has to convert the binary file into a series of equivalent text numbers (that is, if foo.bin contains two bytes $a and $b, then #embed "foo.bin" is supposed to be replaced by 10, 11. There are also a bunch of optional parameters controlling the embedding. It looks like it will be kind of a headache to do, so for now, no.
OTOH file is a general PASM directive, so you can use it in C in a top level __asm block, something like:
Hi,
these days I am wondering about ways to bring together Forth and FlexProp for P2. Probably this would not be as fast and as compact as Taqoz but it would be nice to be able to directly use code others have made. So I am having a look at Forth systems written in C and also considering other ideas.
One idea is, if it might be possible to use the bytecode machine of FlexProp (I think there is one, I have not yet used it?) as the base?
Where do I find a description of the bytecodes for P2? Or the source?
Are there functions like:
1. Start bytecode interpreter with a pointer to the codes?
2. Start native P2 code from the interpreter?
Thank you Christof
Edit:
Have found /backends/nucode/nucode.txt with some description and /sys/nuinterp.spin
Seems to be a stack machine with NOS and TOS like some Forth machines. But has no separate return stack.
Have not yet found the actual interpreting loop. And also not a code list.
@"Christof Eb." said:
Hi,
these days I am wondering about ways to bring together Forth and FlexProp for P2. Probably this would not be as fast and as compact as Taqoz but it would be nice to be able to directly use code others have made. So I am having a look at Forth systems written in C and also considering other ideas.
Have not yet found the actual interpreting loop. And also not a code list.
Could you take a look to the https://8th-dev.com/ website? Ron Aaron created this system, like other Forth' it is not a high-flyer, but he may be willing to contribute?
@"Christof Eb." said:
One idea is, if it might be possible to use the bytecode machine of FlexProp (I think there is one, I have not yet used it?) as the base?
Where do I find a description of the bytecodes for P2? Or the source?
There is one, but it's complicated... the actual interpreter is constructed at compile time and customized to be a match for the program being compiled. So for example if the program never uses the "LDWS" opcode to load a signed 16 bit word, that opcode and its implementation are never included in the interpreter -- only the actually used functions are included. It also goes through and generates "compressed" opcodes that combine the most frequently used operations, to reduce code size, and again that's done dynamically and will be different for each different program that's compiled. So the short answer is that it probably isn't possible to use the nucode interpreter "as is" for Forth. It probably wouldn't be too hard to take sys/nuinterp.spin and manually fill it out to make an interpreter with all the opcodes, which you could use for Forth (but not, as-is, with flexspin).
Are there functions like:
1. Start bytecode interpreter with a pointer to the codes?
That would just be executing from address 0 with ptra holding the stack and the info needed to execute having been pushed onto the stack.
Start native P2 code from the interpreter?
There's an INLINEASM opcode that's used to launch inline assembly; again, it's included only if the program being compiled actually requires this.
Have not yet found the actual interpreting loop. And also not a code list.
The code list is generated by the compiler, based on backends/nucode/nuir.h. The interpreting loop is XBYTE, so it's this piece of code in nuinterp.spin:
The code inside #ifdef ENABLE_DEBUG manually emulates the operation of the hardware XBYTE but with the opportunity to trace execution and/or toggle the tracing output if a $FF opcode is read.
Thanks, Ken! For those attending tomorrow's talk, I'll be presenting some simple demo programs showing inter-language calls. Here's a zip file containing them if you want to follow along at home.
Hi,
perhaps someone can give me some hints?
I try to compile ceForth_33 a Forth written in C in a single file. I checked, that the file is not broken, it compiles with TinyCC in Windows and runs OK.
I can compile it on FlexProp 7.0.0 but it outputs different things and then crashes. The dictionary is not set up correctly. If I compile to nucode, the outputs are different before crashing.
This part of the listing is looking strange to me, but I don't understand, what it is supposed to do. I assume, that it is the array of pointers to functions, but the address information gets lost:
1b8ac 00 00 00 00 | byte $00[66088]
1b8b0 B0 BE 00 00 | long @@@_dat_ + 2088
1b8b4 00 00 00 00 | long (0 {_nop})<<20
1b8b8 00 00 10 00 | long (1 {_bye})<<20
....
Is this generated from?:
void(*primitives[64])(void) = {
/* case 0 */ nop,
/* case 1 */ bye,
....
My crude guessings:
Does FlexProp support pointers to functions?
Has this something to do with the length of int, long, long long?
Little / big endian?
Thanks a lot!
Christof
@"Christof Eb." It crashes on my Linux machine when I compile it there, I'm guessing maybe there's some pointer size dependency? FlexProp does support function pointers, but they're implemented as method pointers; the upper 12 bits is an index into the method table, the lower 20 bits the pointer to the object associated with the method (or 0 for global functions). That's why the table looks a bit funny.
There was a bug in function pointers in 7.0.0, so I would suggest upgrading to 7.0.2, you may get further.
To make sure about Global Register variables in C:
They reside in cog memory, so more than one cog can use them independant frome each other?
How many can we use?
Thank you!
@"Christof Eb." said:
To make sure about Global Register variables in C:
They reside in cog memory, so more than one cog can use them independant frome each other?
Yep.
How many can we use?
Maybe 50 or so. Not sure. 82 with v7.0.3 of Flexspin. You could make Fcache smaller and thereby provide a lot more space for these statics.
If this is for parameter passing to Pasm2 code then it might be better to approach how I did the SD card driver. Flexspin supports a way to quickly copy a whole structure from hubRAM to cogRAM and reasonably supports symbolic referencing of those variables in both memories. In hubRAM they are the structure members. In cogRAM using Fcache'd code they are RES allocations that are ordered and named the same as the structure members.
@"Christof Eb." said:
To make sure about Global Register variables in C:
They reside in cog memory, so more than one cog can use them independant frome each other?
Yep.
How many can we use?
Maybe 50 or so. Not sure. 82 with v7.0.3 of Flexspin. You could make Fcache smaller and thereby provide a lot more space for these statics.
If this is for parameter passing to Pasm2 code then it might be better to approach how I did the SD card driver. Flexspin supports a way to quickly copy a whole structure from hubRAM to cogRAM and reasonably supports symbolic referencing of those variables in both memories. In hubRAM they are the structure members. In cogRAM using Fcache'd code they are RES allocations that are ordered and named the same as the structure members.
Thank you! I need about 10 of them them as static variables to run the same code in more than one cog. Registers for the virtual Forth machine(s). Good to know now, that this concept will work.
Comments
However, my Basic interpreter doesn't compile with 7.0.0 The error reported is
ffunicode.c:15565: error: bad cast of cvt1
?????
FlexBasic also accepts recv. So I prepared getchar() function that waits for a keypress and returns an ASCII code.
Then this "program" in bf:
+[,.]
prints on the screen a character that was pressed.
I edited the line 15565 of ffunicode.c to
p = uc < 0x1000 ? (WORD*) cvt1 : (WORD *) cvt2;
Now it compiles. However I don't know if this is a proper way to correct this and why the C compiler cannot do the assign without a manual added cast.
Aargh, that's a new bug in the ?: parsing code. It's fixed in github now, but your work-around of adding explicit casts is a good one.
@ersmith Can you do muldiv64 in C? Not seeing it... Maybe need to include a helper.spin2 type object in C to get that?
It doesn't seem to be documented, I need to update the docs.
Hi,
does FlexProp C support raw literals?
I want to port a program, which has
const char boot[] = R"""(
then a multi line text comes, which ends with
)""";
I get:
error: Unterminated string literal, skipped the line
What is the best way to work around?
Thanks!
No. That's a feature from the C++11 standard, which is way beyond what FlexC supports.
You'll have to turn the multi-line text into ordinary text with embedded new lines; something
like:
That is, put a
"
at the beginning of each line and a\n"
at the end of the line.This works because C will automatically merge adjacent strings, so
"hello " "world"
becomes"hello world"
.I mean we do have digit seperators (
int x = 1'000'000
) from C++14 / C23Can we get the #embed directive?
https://stackoverflow.com/questions/74621610/what-is-the-purpose-of-the-new-c23-embed-directive
Seems like should be relatively easy since Spin2 has it already with "file"?
Thanks for the reply!
Unfortunately this seems to be one of the smaller problems. I now have found a && with only one operand, which has to be a "move" thingy. And also something does not work with a struct or union. I will have to give up this port as I do not understand too much of the intentions....
@"Christof Eb."
Maybe there's a converter from C++ to C ?
This looks like one: https://www.codeconvert.ai/c++-to-c-converter
#embed
goes way beyondfile
; because#embed
is a preprocessor directive, it can appear anywhere in the source, and it appears it has to convert the binary file into a series of equivalent text numbers (that is, if foo.bin contains two bytes $a and $b, then#embed "foo.bin"
is supposed to be replaced by10, 11
. There are also a bunch of optional parameters controlling the embedding. It looks like it will be kind of a headache to do, so for now, no.OTOH
file
is a general PASM directive, so you can use it in C in a top level__asm
block, something like:@ersmith that file looks good. Have to remember that one...
Hi,
these days I am wondering about ways to bring together Forth and FlexProp for P2. Probably this would not be as fast and as compact as Taqoz but it would be nice to be able to directly use code others have made. So I am having a look at Forth systems written in C and also considering other ideas.
One idea is, if it might be possible to use the bytecode machine of FlexProp (I think there is one, I have not yet used it?) as the base?
Where do I find a description of the bytecodes for P2? Or the source?
Are there functions like:
1. Start bytecode interpreter with a pointer to the codes?
2. Start native P2 code from the interpreter?
Thank you Christof
Edit:
Have found /backends/nucode/nucode.txt with some description and /sys/nuinterp.spin
Seems to be a stack machine with NOS and TOS like some Forth machines. But has no separate return stack.
Have not yet found the actual interpreting loop. And also not a code list.
@"Christof Eb." , have a look at @Wuerfel_21 's excellent Web site. She describes the bytecode instructions here
Bob
Thank you! Ok, so there must be a code list somehow in LUT.
@bob_g4bby
Do you know of any single- stack implementation of Forth?
Could you take a look to the https://8th-dev.com/ website? Ron Aaron created this system, like other Forth' it is not a high-flyer, but he may be willing to contribute?
There is one, but it's complicated... the actual interpreter is constructed at compile time and customized to be a match for the program being compiled. So for example if the program never uses the "LDWS" opcode to load a signed 16 bit word, that opcode and its implementation are never included in the interpreter -- only the actually used functions are included. It also goes through and generates "compressed" opcodes that combine the most frequently used operations, to reduce code size, and again that's done dynamically and will be different for each different program that's compiled. So the short answer is that it probably isn't possible to use the nucode interpreter "as is" for Forth. It probably wouldn't be too hard to take sys/nuinterp.spin and manually fill it out to make an interpreter with all the opcodes, which you could use for Forth (but not, as-is, with flexspin).
That would just be executing from address 0 with ptra holding the stack and the info needed to execute having been pushed onto the stack.
There's an INLINEASM opcode that's used to launch inline assembly; again, it's included only if the program being compiled actually requires this.
The code list is generated by the compiler, based on backends/nucode/nuir.h. The interpreting loop is XBYTE, so it's this piece of code in nuinterp.spin:
The code inside
#ifdef ENABLE_DEBUG
manually emulates the operation of the hardware XBYTE but with the opportunity to trace execution and/or toggle the tracing output if a $FF opcode is read.@"Christof Eb."
Do you know of any single- stack implementation of Forth? No, I don't
Hey all, Eric is talking FlexProp at tomorrow's Propeller Live Forum. Bring your questions and money for him! Signup here https://www.parallax.com/propeller-live-forum-february-12th-2025/ and see ya tomorrow!
Ken Gracey
Thanks, Ken! For those attending tomorrow's talk, I'll be presenting some simple demo programs showing inter-language calls. Here's a zip file containing them if you want to follow along at home.
Also, I'll point out that there is a new bugfix release (7.0.2) available both at github and at Patreon. See my signature for links to it.
Hi,
perhaps someone can give me some hints?
I try to compile ceForth_33 a Forth written in C in a single file. I checked, that the file is not broken, it compiles with TinyCC in Windows and runs OK.
I can compile it on FlexProp 7.0.0 but it outputs different things and then crashes. The dictionary is not set up correctly. If I compile to nucode, the outputs are different before crashing.
This part of the listing is looking strange to me, but I don't understand, what it is supposed to do. I assume, that it is the array of pointers to functions, but the address information gets lost:
Is this generated from?:
My crude guessings:
Does FlexProp support pointers to functions?
Has this something to do with the length of int, long, long long?
Little / big endian?
Thanks a lot!
Christof
Edit ZIP was missing, sorry.
@"Christof Eb." id try playing with optimization level, increasing heap size, and increasing fcache size…
Depending on the code…
@"Christof Eb." It crashes on my Linux machine when I compile it there, I'm guessing maybe there's some pointer size dependency? FlexProp does support function pointers, but they're implemented as method pointers; the upper 12 bits is an index into the method table, the lower 20 bits the pointer to the object associated with the method (or 0 for global functions). That's why the table looks a bit funny.
There was a bug in function pointers in 7.0.0, so I would suggest upgrading to 7.0.2, you may get further.
To make sure about Global Register variables in C:
They reside in cog memory, so more than one cog can use them independant frome each other?
How many can we use?
Thank you!
Yep.
Maybe 50 or so. Not sure. 82 with v7.0.3 of Flexspin. You could make Fcache smaller and thereby provide a lot more space for these statics.
If this is for parameter passing to Pasm2 code then it might be better to approach how I did the SD card driver. Flexspin supports a way to quickly copy a whole structure from hubRAM to cogRAM and reasonably supports symbolic referencing of those variables in both memories. In hubRAM they are the structure members. In cogRAM using Fcache'd code they are
RES
allocations that are ordered and named the same as the structure members.Thank you! I need about 10 of them them as static variables to run the same code in more than one cog. Registers for the virtual Forth machine(s). Good to know now, that this concept will work.