I've released a binary for the final version 5.9.15 on my Patreon page. The source is tagged in github as v5.9.15 for those who prefer to build it themselves. The major GUI changes are the Mac bug fixes mentioned above. On the compiler side, the changes are mainly bug fixes and include:
- Added definitions for PR0-PR7 registers in Spin2
- Added ORGH/END inline assembly in Spin2 for non-optimized hub based inline asm.
- Added MUXQ optimization for P2 pinwrite.
- Fixed several missing 64 bit arithmetic operations.
- Fixed evaluation of unary `+`.
- Fixed incorrect optimization around FCACHE.
- Made first 16 LUT registers reserved for user code.
- Prevent REP loop optimization in ORG and volatile asm
FlexProp 5.9.16 is now available, on both github and Patreon. This is mainly a bug fix release, with a focus on 64 bit integers (which should fully work now on both the ASM and bytecode back ends).
Is there a way to have global variables in cog ram?
Like: register int x; ?
Thank you very much, Christof
Edit: I found "Most of COG RAM is used by the compiler, except that $1e0-$1ef are left free for application use."
How can I tell the compiler to access a cog memory location $1E0 as a variable in C?
Is there a way to have global variables in cog ram?
Like: register int x; ?
Thank you very much, Christof
Edit: I found "Most of COG RAM is used by the compiler, except that $1e0-$1ef are left free for application use."
How can I tell the compiler to access a cog memory location $1E0 as a variable in C?
Unfortunately there is not any way right now to declare global register variables. It seems like it might be a useful feature though, and I will look into it. Thank you for the suggestion.
Is there a way to have global variables in cog ram?
Like: register int x; ?
Thank you very much, Christof
Edit: I found "Most of COG RAM is used by the compiler, except that $1e0-$1ef are left free for application use."
How can I tell the compiler to access a cog memory location $1E0 as a variable in C?
Unfortunately there is not any way right now to declare global register variables. It seems like it might be a useful feature though, and I will look into it. Thank you for the suggestion.
Thanks, Eric for the quick replay and that you want to look at it.
I have tried
_INA= 3017;
and
_INA++;
Which is compiled just very well.
So perhaps fixed names like: "_COGMEM_1E0" would be relatively easy to implement?
Can I perhaps use _IJMP3 and it's brothers in a cog, that runs a C-function as a local variable? "_IJMP3=123;" did not crash... Gets overwritten!
Thanks again! Christof
@ersmith said:
Unfortunately there is not any way right now to declare global register variables. It seems like it might be a useful feature though, and I will look into it. Thank you for the suggestion.
Thanks, Eric for the quick replay and that you want to look at it.
I have tried
_INA= 3017;
and
_INA++;
Which is compiled just very well.
So perhaps fixed names like: "_COGMEM_1E0" would be relatively easy to implement?
Oh! Yes, actually, on the P2 the names _PR0 ... _PR7 are available for the memory locations 0x1e0 to 0x1e7. So instead of:
register int *pc;
register unsigned accumulator;
you could do:
#define pc ((int *)_PR0)
#define accumulator ((unsigned)_PR1)
That should work in the current version of FlexProp.
@ersmith said:
Unfortunately there is not any way right now to declare global register variables. It seems like it might be a useful feature though, and I will look into it. Thank you for the suggestion.
Thanks, Eric for the quick replay and that you want to look at it.
I have tried
_INA= 3017;
and
_INA++;
Which is compiled just very well.
So perhaps fixed names like: "_COGMEM_1E0" would be relatively easy to implement?
Oh! Yes, actually, on the P2 the names _PR0 ... _PR7 are available for the memory locations 0x1e0 to 0x1e7. So instead of:
register int *pc;
register unsigned accumulator;
you could do:
#define pc ((int *)_PR0)
#define accumulator ((unsigned)_PR1)
That should work in the current version of FlexProp.
Unfortunately # is a special character to the C preprocessor, so it's very hard to get it into a macro. There are some hacks involving multiple definitions, but really your best bet is to probably avoid macros and to just write a small function which will be inlined. Or, you could do the address calculation in C; something like:
MmuReg = ((((unsigned)address)>>13)+0x1e8)<<2;
should generate the same code as the first 4 instructions in your inline assembly.
Thank you, Eric, for the explanation! Perhaps you assembler could be modified, that it accepts some other character in place of # ? Just an idea. & ? % ? # is quite useful! You already introduced ; .
These _PRx come quite handy. Perhaps you could provide more of them, that all free cog ram can be accessed in this way? Well, of course, full global register variables would be nice....
My code above shall use 8 longs in cog ram starting at $1e8 as a table. Out of the selected long _PR7 shall select one byte. I don't know, if this code does, what I want it to do....
@"Christof Eb." said:
Thank you, Eric, for the explanation! Perhaps you assembler could be modified, that it accepts some other character in place of # ? Just an idea. & ? % ? # is quite useful! You already introduced ; .
I've checked in a change to allow the use of = in place of #.
These _PRx come quite handy. Perhaps you could provide more of them, that all free cog ram can be accessed in this way? Well, of course, full global register variables would be nice....
We don't really know how much free cog ram there is until compilation is finished. But the current github version does support declaring global register variables with extern register, so you can have many more of them.
But the current github version does support declaring global register variables with extern register, so you can have many more of them.
That sounds great. Unfortunately I do not understand, what "extern register" means. Why "extern"?
It's a sign that the variable is global (shared by all functions).
Edit: There seems to be no speed advantage with "extern register".
Are you building flexspin yourself with the most recent github version of spin2cpp? Obviously what things get faster depend on the particular code, so there's no guarnatee that "extern register" variables will help performance, but generally they will.
Thank you for Your fast reply!
I use the version for Windows. Zip.
I always thought, that extern is used, when you reference something, that will be brought by a linker.
Always learning.
One other question: Can you force inlining of a function or enlarge the size limit for this?
Please be aware, that I am very thankful for your tool and for your help!
Eric,
A couple of points on the extern register update:
The documentation formatting is a little broken (missing content) by using a mono font, eg:
It seems like these extern register variables should be usable in inline pasm as a register symbol, but I'm not getting any joy trying to use as such. Eg: error: Symbol greg is not usable in inline asm
Are you building flexspin yourself with the most recent github version of spin2cpp? Obviously what things get faster depend on the particular code, so there's no guarnatee that "extern register" variables will help performance, but generally they will.
Edit: Ah, I found spin2cpp. Well, I already have to fight in this project with Windows, mc6809, coco-3, OS9, C, FlexC, P2 memory, P2Pasm, documentation of P2,.... It took me hours, to find out, how altgb + getbyte is supposed to work.
I therefore would be really grateful, if these features could be included in a new executable zip!
@"Christof Eb." said:
I always thought, that extern is used, when you reference something, that will be brought by a linker.
Always learning.
I should clarify that "extern register" is a FlexC only thing, it is not standard C. In standard C "extern" does indeed indicate something from another file, and there is no way to declare register variables that are global ("register" is only valid for local variables, and is generally ignored by most compilers because they try to keep local values in registers anyway.)
One other question: Can you force inlining of a function or enlarge the size limit for this?
No, there isn't. An alternative is to put the function into COG or LUT memory, which will allow it to run quite quickly.
Are you building flexspin yourself with the most recent github version of spin2cpp? Obviously what things get faster depend on the particular code, so there's no guarnatee that "extern register" variables will help performance, but generally they will.
Yes, the "extern register" feature is only implemented in 5.9.17, which isn't released yet. You can build pre-release versions from the source code. I also release pre-release ("beta") versions on patreon periodically. Otherwise, you'll have to wait for the next full release, which should be fairly soon.
@evanh said:
Eric,
A couple of points on the extern register update:
The documentation formatting is a little broken (missing content) by using a mono font, eg:
It seems like these extern register variables should be usable in inline pasm as a register symbol, but I'm not getting any joy trying to use as such. Eg: error: Symbol greg is not usable in inline asm
Thanks Evan, I think those should be fixed in github now.
The documentation issue might be an incompatibility of my reader. I'm using KDE's Okular. Here's the complete sub-section rendered. There is multiple cases in all of your .md documents. This is just one.
As you can see it first messes up at the #define with the # missing. And doesn't fully recover again until the following sub-section on Classes.
The documentation issue might be an incompatibility of my reader. I'm using KDE's Okular. Here's the complete sub-section rendered. There is multiple cases in all of your .md documents. This is just one.
Yes, this is Okular not recognizing the fenced code block and attempting to parse its contents as markdown.
Comments
Eric,
The changes seem to have fixed my issues as well. I will be testing out the serial stuff over the next few days.
I've released a binary for the final version 5.9.15 on my Patreon page. The source is tagged in github as v5.9.15 for those who prefer to build it themselves. The major GUI changes are the Mac bug fixes mentioned above. On the compiler side, the changes are mainly bug fixes and include:
FlexProp 5.9.16 is now available, on both github and Patreon. This is mainly a bug fix release, with a focus on 64 bit integers (which should fully work now on both the ASM and bytecode back ends).
Thank you, Eric! Having 64-bit capability is a big plus for me.
Indeed. Do the math.
Ah, that brings back memories... I was at Atari in those years, and worked on some Jaguar games.
Oh wow. I need to know the ersmith atari deep lore.
@ersmith
Many thanks, Eric
Craig
@ersmith
Using flexC in this project: https://forums.parallax.com/discussion/174794/towards-os9-operating-system-on-p2#latest
The cpuregisters in file mc6809P2B.c should be FAST. There is a zip of the code in #3.
Is there a way to have global variables in cog ram?
Like: register int x; ?
Thank you very much, Christof
Edit: I found "Most of COG RAM is used by the compiler, except that $1e0-$1ef are left free for application use."
How can I tell the compiler to access a cog memory location $1E0 as a variable in C?
Unfortunately there is not any way right now to declare global register variables. It seems like it might be a useful feature though, and I will look into it. Thank you for the suggestion.
Thanks, Eric for the quick replay and that you want to look at it.
I have tried
_INA= 3017;
and
_INA++;
Which is compiled just very well.
So perhaps fixed names like: "_COGMEM_1E0" would be relatively easy to implement?
Can I perhaps use _IJMP3 and it's brothers in a cog, that runs a C-function as a local variable? "_IJMP3=123;" did not crash... Gets overwritten!
Thanks again! Christof
Oh! Yes, actually, on the P2 the names _PR0 ... _PR7 are available for the memory locations 0x1e0 to 0x1e7. So instead of:
you could do:
That should work in the current version of FlexProp.
Whow, You made my day!
Question: Can't you use constants in inline assembler macros?
MmuRegisters is a 4*8 array of bytes, which shall be located in cog ram
// To replace MmuRegisters[MmuState][address>>13] // MmuState is in _PR7 // MmuReg will hold the relevant content #define MmuReg _PR6 #define GetMR(address) \ __asm { \ mov pr6, address; \ shr pr6, #13; \ add pr6, #$1e8; \ shl pr6, #2; \ altgb pr6, pr7; \ getbyte pr6; \ }I get: "error: Not a formal parameter "13""
Unfortunately
#is a special character to the C preprocessor, so it's very hard to get it into a macro. There are some hacks involving multiple definitions, but really your best bet is to probably avoid macros and to just write a small function which will be inlined. Or, you could do the address calculation in C; something like:should generate the same code as the first 4 instructions in your inline assembly.
Thank you, Eric, for the explanation! Perhaps you assembler could be modified, that it accepts some other character in place of # ? Just an idea. & ? % ? # is quite useful! You already introduced ; .
These _PRx come quite handy. Perhaps you could provide more of them, that all free cog ram can be accessed in this way? Well, of course, full global register variables would be nice....
My code above shall use 8 longs in cog ram starting at $1e8 as a table. Out of the selected long _PR7 shall select one byte. I don't know, if this code does, what I want it to do....
Eric,
Finally giving C a try on the P2. I am getting a compile error on a system library
/Users/xxxxx/flexprop/include/time.h:47: error: syntax error, unexpected __fromfile, expecting ',' or ';'
clock_t clock(void) _IMPL("libc/sys/propeller/clock.c");I am running the latest from github.
I've checked in a change to allow the use of
=in place of#.We don't really know how much free cog ram there is until compilation is finished. But the current github version does support declaring global register variables with
extern register, so you can have many more of them.Could you post your source code, or at least a snippet of it? Are you using flexprop, or the command line? Is this for a P1 or P2?
That sounds great. Unfortunately I do not understand, what "extern register" means. Why "extern"?
Edit: There seems to be no speed advantage with "extern register".
It's a sign that the variable is global (shared by all functions).
Are you building flexspin yourself with the most recent github version of spin2cpp? Obviously what things get faster depend on the particular code, so there's no guarnatee that "extern register" variables will help performance, but generally they will.
Thank you for Your fast reply!
I use the version for Windows. Zip.
I always thought, that extern is used, when you reference something, that will be brought by a linker.
Always learning.
One other question: Can you force inlining of a function or enlarge the size limit for this?
Please be aware, that I am very thankful for your tool and for your help!
Eric,
A couple of points on the extern register update:
The documentation formatting is a little broken (missing content) by using a mono font, eg:
It seems like these extern register variables should be usable in inline pasm as a register symbol, but I'm not getting any joy trying to use as such. Eg:
error: Symbol greg is not usable in inline asmI am using the windows version 5.9.16 https://github.com/totalspectrum/flexprop/releases/tag/v5.9.16 and it makes no difference, if I use extern. The variable gets loaded from hub mem.
Edit: Ah, I found spin2cpp. Well, I already have to fight in this project with Windows, mc6809, coco-3, OS9, C, FlexC, P2 memory, P2Pasm, documentation of P2,.... It took me hours, to find out, how altgb + getbyte is supposed to work.
I therefore would be really grateful, if these features could be included in a new executable zip!
I should clarify that "extern register" is a FlexC only thing, it is not standard C. In standard C "extern" does indeed indicate something from another file, and there is no way to declare register variables that are global ("register" is only valid for local variables, and is generally ignored by most compilers because they try to keep local values in registers anyway.)
No, there isn't. An alternative is to put the function into COG or LUT memory, which will allow it to run quite quickly.
Yes, the "extern register" feature is only implemented in 5.9.17, which isn't released yet. You can build pre-release versions from the source code. I also release pre-release ("beta") versions on patreon periodically. Otherwise, you'll have to wait for the next full release, which should be fairly soon.
Thanks Evan, I think those should be fixed in github now.
Cool, inline pasm sees them now.
The documentation issue might be an incompatibility of my reader. I'm using KDE's Okular. Here's the complete sub-section rendered. There is multiple cases in all of your .md documents. This is just one.
As you can see it first messes up at the
#definewith the # missing. And doesn't fully recover again until the following sub-section on Classes.Yes, this is Okular not recognizing the fenced code block and attempting to parse its contents as markdown.
Got any recommendations of a better reader?