Then do a SEUSSF or SEUSSR for good measure. You'd better run those through your tester.
Forgive me, Guys, but I had another quick detour before getting back on the docs. In getting the ROM Monitor code moved into hub space, where possible, to free up registers to maximize the internal data/string buffer, I realized we were missing some important instructions, which I had been putting off. We needed instructions to set up circular buffers with INDA/INDB using variables. Otherwise, hub code would have a problem, not being able to self-modify as easily as cog code to use FIXINDA/FIXINDB. I don't think you'd really even want self-modifying hub code, anyway, as it would be big and preclude multi-execution. We now have these:
CIRINDA D,S/# 'Set up a circular buffer with INDA, where start is S/# and end is S/# + D.
CIRINDB D,S/# 'Set up a circular buffer with INDB, where start is S/# and end is S/# + D.
...and to round things out...
LODINDS D/#,S/# 'Set INDB to D/# and set INDA to S/#, span is $000..$1FF.
I've spent a lot of time over that last several weeks making sure we have completeness in all the addressing instructions, as these enable smooth sailing. Everything's running like a song now. In moving the ROM Monitor subroutines out of the cog registers and into hub space by placing them under an ORGH, I didn't have to change anything, except some self-modifying code. The CALLs worked just as before, but now there was a ton of registers freed up, since the subroutines were outside of the cog. I was half-expecting some unforeseen wipeout, but it worked perfectly. This hub exec is a whole new ballgame.
Would you adventurous ones like me to post a DE2-115 configuration file before the docs are all caught up? It would have the latest instruction list at the end, but the descriptions will be updated over the next few days.
Would you adventurous ones like me to post a DE2-115 configuration file before the docs are all caught up? It would have the latest instruction list at the end, but the descriptions will be updated over the next few days.
Would you adventurous ones like me to post a DE2-115 configuration file before the docs are all caught up? It would have the latest instruction list at the end, but the descriptions will be updated over the next few days.
Would you adventurous ones like me to post a DE2-115 configuration file before the docs are all caught up? It would have the latest instruction list at the end, but the descriptions will be updated over the next few days.
...Everything's running like a song now. In moving the ROM Monitor subroutines out of the cog registers and into hub space by placing them under an ORGH, I didn't have to change anything, except some self-modifying code. The CALLs worked just as before, but now there was a ton of registers freed up, since the subroutines were outside of the cog. I was half-expecting some unforeseen wipeout, but it worked perfectly. This hub exec is a whole new ballgame.
What is the new memory usage/overhead in COG and HUB ram areas for the Monitor ?
What is the new memory usage/overhead in COG and HUB ram areas for the Monitor ?
Well, it doesn't take hub RAM, but uses some ROM, of course. Inside the cog, less than half of the RAM holds code, while the rest is variables, including a 128-long data/string buffer. I could have gotten almost all the code into the hub ROM, but I could only move out what was addressed above $800 ($200 long address), since anything below that would be interpreted as an internal cog address by the cog.
I think your idea is perfect (from post page 318 about for the spin compiler). If the spin compiler plays nice in the same memory space as the propGCC, then the two can be used interchangeably and therefore so can all the objects/drivers. Physical and software platform fragmentation has been a serious adoption limiter for the prop-1. It can be completely avoided with prop 2!
Physical and software platform fragmentation has been a serious adoption limiter for the prop-1. It can be completely avoided with prop 2!
This requires defining an application binary interface (ABI) which is usually the purview of the operating system designer, or in the absence of an OS the compiler writer such as propGCC did. Fully defining an ABI for the Prop2 is probably going to satisfy nobody, but maybe there could be some conventions that the community hashes out and adopts?
I think your idea is perfect (from post page 318 about for the spin compiler). If the spin compiler plays nice in the same memory space as the propGCC, then the two can be used interchangeably and therefore so can all the objects/drivers. Physical and software platform fragmentation has been a serious adoption limiter for the prop-1. It can be completely avoided with prop 2!
On page 318 Heater is commenting about the CHKxxx instructions. I don't see any reference to the spin compiler from Heater. What idea are you referring to?
A better plan would be for future PASM drivers to be written in such a way that they can be used from any language. Just a binary "blob" that you load and start a COG and talk to through HUB memory.
I have been advocating this for years (for example, see here). But I now realize it hasn't got a hope of ever getting up - it violates a programmer's constitutional right to write their code however they want.
To make something like that gain traction, "center of gravity" is needed, and that means a compelling body of code using the technique.
If it is sufficiently compelling, adding things to it, and or modifying things to work will be worth it for a much larger fraction of programmers.
Otherwise, it competes with "I just want it to work, and I want to make whatever it is go" resulting in a lot of approaches.
Further, it also competes with "but this way is better, easier, etc...." also resulting in a lot of approaches.
The reason for this dynamic is we can't actually make anybody do anything, but we can make doing it in desirable ways more worth doing. The key is use value. If such a compelling body of code had very high use value, a larger number of people will want to take advantage of that value, resulting is the more desirable path being the one of least resistence.
To make something like that gain traction, "center of gravity" is needed, and that means a compelling body of code using the technique.
You mean .... like the Catalina C compiler and the large collection of OBEX objects that it has converted to use this technique?
- serial comms (at least four of these, based on different OBEX objects)
- keyboard
- mouse
- vga (hi and lo res versions)
- tv (hi and lo res versions)
- spi
- i2c
- sdcard (two of these)
- eeprom
- sound
- gamepad
- floating point
- graphics (TV and VGA versions)
- real-time clock
All based on minor edits to existing PASM objects from the OBEX, and distributed with Catalina, and which can be used from both Spin and C.
Not to mention those added to Catalina by others (I am aware of quite a few, but since they are proprietary they are not included in the Catalina distribution).
It's my opinion that the development environment for P2 start out of the gate supporting ASM, C++, and Spin2. That way we are all on the same page regarding the obex. None of this Spin/ASM with that other C thing tacked on the side like the P1, with so much documentation referring to Spin.
All 3 languages in the same package, or bust.
Calling conventions for C++ or Spin functions need to be the same as well (within normal use cases).
Yes I do Ross. The efforts to enable C to make better use of what has been done are great. This carried over to P2 will make an impact. And the chip will be faster, more roomy, etc... which also means more code targets are appropriate for potential reuse.
We can further enhance this with things like templates for a PASM COG, though on P2 who knows what those will look like? Lots of possibilities, and frankly, more reasons to use the HLL to weave it all together. On P1, we basically have the PASM COG. P2 has that, plus tasks, execute out of HUB, and such.
So, we can add PASM library or module to the list as part of the thing maybe in the HUB, part in COG, and with task 3, part swappable in and out of COG. Interesting times!
And by template I mean an empty COG code frame, with the mailboxes setup, maybe something like a multiple blinky driver that takes pin number, intensity[ies], whatever[ers]. People can pull that up, much like we saw with video template type drivers, write in what they want, and ideally having the mailbox setup, easily extended, commented, etc... means just going with it, "type your PASM in right here" style.
On P1, lots of things got done however they got done, and to be fair, the argument wasn't there like it is today. P2 is large enough that more people should see the return on investments in things like this. My thoughts anyway.
Having C and Spin/PASM support from launch day does nothing to help make PASM created in Spin be usable by C.
C and Spin calling conventions will never be the same as unless there is a radical change in Spin. i.e. it no longer uses byte code but compiles directly to machine code.
Heck, you can't call C++ methods from C, How can we expect C to call Spin methods?
To make PASM written in Spin or C usable in either language, or other languages, it has to be decoupled from the HLL. It has to be more like those binary blobs of firmware that operating systems load into peripheral devices to make the run.
That means changing Spin a bit to impose some simple rules. like:
1) PASM sections should not rely on variables or constants defined in Spin
2) Spin code should not be allowed to "poke" values into the DAT section that will be loaded to COG at COG start (C programs won't know the addresses of those values.)
3) All parameters must be passed into PASM code via PAR at start up, i.e. not rely on those "pokes" above.
These ideas and techniques/rules for making PASM reusable across different language systems have been debated here for years. RossH even documented what it would take very nicely.
However I don't think Spin users would accept such rules being introduced to Spin.
Yeah, I don't think those SPIN rules make a lot of sense.
However, it's totally possible. Again, a compelling body of code will present high use value. The higher that use value is, the more likely we get easily callable or easily modified to be callable programs we can add to that body of code.
Ah, "impossible", that magic word that get's thing done around here. Even before you have used it sometimes !
Actually I think I was confusing two issues in my "impossible" rant above.
1) Combining Spin and C in the same program. Or at least being able to call from one into another even if not both ways around. That seems to be what spinwrap does. I will have to look more at that.
2) Making PASM code universally usable across all languages as binary blobs no matter if it was written in a Spin object or in GAS or whatever. Does Spin wrap address that ?
I support David's efforts in SpinWrap, but he would acknowledge that this is not an optimal way to integrate PASM objects (as opposed to Spin objects).
It is too slow for some purposes, costs an unnecessary cog, and some unnecessary Hub RAM space. I'm not claiming Catalina's method is optimal, but it does everything SpinWrap does, and much more (e.g. locking, cog management etc).
And it is more efficient in both cog usage and hub ram usage.
Is there any chance of using multithreading to do VGA output from SDRAM on a DE0-Nano?
Yes.
I'm compiling the DE0-Nano now. I had to remove the PIX, CORDIC, CTRB, SERB, and waveform output from CTRA to get things to fit. If this compile works, I'll try putting the waveform output back in for CTRA. Anyway, you need the VID and XFR blocks to do multithreaded VGA w/SDRAM, and those blocks are both in the DE0-Nano compile. For the SDRAM writing/reading, you'll need to be single-tasking because that requires exact timing.
Comments
ESWAP8 D results
Edit: Try this trick
ESWAP4 D ESWAP8 D Before: Flags: Z=0 C=0 D=$1234_5678 %0001_0010_0011_0100_0101_0110_0111_1000 35419896 S=$0000_0000 %0000_0000_0000_0000_0000_0000_0000_0000 0 After: Flags: Z=0 C=0 D=$2143_6587 %0010_0001_0100_0011_0110_0101_1000_0111 558065031 S=$0000_0000 %0000_0000_0000_0000_0000_0000_0000_0000 0Swaps nibbles within the bytes.
Then do a SEUSSF or SEUSSR for good measure. You'd better run those through your tester.
Forgive me, Guys, but I had another quick detour before getting back on the docs. In getting the ROM Monitor code moved into hub space, where possible, to free up registers to maximize the internal data/string buffer, I realized we were missing some important instructions, which I had been putting off. We needed instructions to set up circular buffers with INDA/INDB using variables. Otherwise, hub code would have a problem, not being able to self-modify as easily as cog code to use FIXINDA/FIXINDB. I don't think you'd really even want self-modifying hub code, anyway, as it would be big and preclude multi-execution. We now have these:
CIRINDA D,S/# 'Set up a circular buffer with INDA, where start is S/# and end is S/# + D.
CIRINDB D,S/# 'Set up a circular buffer with INDB, where start is S/# and end is S/# + D.
...and to round things out...
LODINDS D/#,S/# 'Set INDB to D/# and set INDA to S/#, span is $000..$1FF.
I've spent a lot of time over that last several weeks making sure we have completeness in all the addressing instructions, as these enable smooth sailing. Everything's running like a song now. In moving the ROM Monitor subroutines out of the cog registers and into hub space by placing them under an ORGH, I didn't have to change anything, except some self-modifying code. The CALLs worked just as before, but now there was a ton of registers freed up, since the subroutines were outside of the cog. I was half-expecting some unforeseen wipeout, but it worked perfectly. This hub exec is a whole new ballgame.
Would you adventurous ones like me to post a DE2-115 configuration file before the docs are all caught up? It would have the latest instruction list at the end, but the descriptions will be updated over the next few days.
<Gnaws right arm off to get it!> Yes please!
What is the new memory usage/overhead in COG and HUB ram areas for the Monitor ?
Bingo!
Well, it doesn't take hub RAM, but uses some ROM, of course. Inside the cog, less than half of the RAM holds code, while the rest is variables, including a 128-long data/string buffer. I could have gotten almost all the code into the hub ROM, but I could only move out what was addressed above $800 ($200 long address), since anything below that would be interpreted as an internal cog address by the cog.
I think your idea is perfect (from post page 318 about for the spin compiler). If the spin compiler plays nice in the same memory space as the propGCC, then the two can be used interchangeably and therefore so can all the objects/drivers. Physical and software platform fragmentation has been a serious adoption limiter for the prop-1. It can be completely avoided with prop 2!
This requires defining an application binary interface (ABI) which is usually the purview of the operating system designer, or in the absence of an OS the compiler writer such as propGCC did. Fully defining an ABI for the Prop2 is probably going to satisfy nobody, but maybe there could be some conventions that the community hashes out and adopts?
But whilst we are at it, my thing there was all about how text processing instructions should not be polluting the instruction set space.
UCASE being a non-starter because it cannot reliably uppercase the character set of the user, think
I have been advocating this for years (for example, see here). But I now realize it hasn't got a hope of ever getting up - it violates a programmer's constitutional right to write their code however they want.
Ross.
If it is sufficiently compelling, adding things to it, and or modifying things to work will be worth it for a much larger fraction of programmers.
Otherwise, it competes with "I just want it to work, and I want to make whatever it is go" resulting in a lot of approaches.
Further, it also competes with "but this way is better, easier, etc...." also resulting in a lot of approaches.
The reason for this dynamic is we can't actually make anybody do anything, but we can make doing it in desirable ways more worth doing. The key is use value. If such a compelling body of code had very high use value, a larger number of people will want to take advantage of that value, resulting is the more desirable path being the one of least resistence.
You mean .... like the Catalina C compiler and the large collection of OBEX objects that it has converted to use this technique?
- serial comms (at least four of these, based on different OBEX objects)
- keyboard
- mouse
- vga (hi and lo res versions)
- tv (hi and lo res versions)
- spi
- i2c
- sdcard (two of these)
- eeprom
- sound
- gamepad
- floating point
- graphics (TV and VGA versions)
- real-time clock
All based on minor edits to existing PASM objects from the OBEX, and distributed with Catalina, and which can be used from both Spin and C.
Not to mention those added to Catalina by others (I am aware of quite a few, but since they are proprietary they are not included in the Catalina distribution).
Ross.
It's my opinion that the development environment for P2 start out of the gate supporting ASM, C++, and Spin2. That way we are all on the same page regarding the obex. None of this Spin/ASM with that other C thing tacked on the side like the P1, with so much documentation referring to Spin.
All 3 languages in the same package, or bust.
Calling conventions for C++ or Spin functions need to be the same as well (within normal use cases).
We can further enhance this with things like templates for a PASM COG, though on P2 who knows what those will look like? Lots of possibilities, and frankly, more reasons to use the HLL to weave it all together. On P1, we basically have the PASM COG. P2 has that, plus tasks, execute out of HUB, and such.
So, we can add PASM library or module to the list as part of the thing maybe in the HUB, part in COG, and with task 3, part swappable in and out of COG. Interesting times!
And by template I mean an empty COG code frame, with the mailboxes setup, maybe something like a multiple blinky driver that takes pin number, intensity[ies], whatever[ers]. People can pull that up, much like we saw with video template type drivers, write in what they want, and ideally having the mailbox setup, easily extended, commented, etc... means just going with it, "type your PASM in right here" style.
On P1, lots of things got done however they got done, and to be fair, the argument wasn't there like it is today. P2 is large enough that more people should see the return on investments in things like this. My thoughts anyway.
I can assure you it will be this way.
Ken Gracey
That's great, Ken. Any news on the Spin2 compiler progress? I have heard there was one, but I have not seen much discussion about it in the forums.
Ross.
C and Spin calling conventions will never be the same as unless there is a radical change in Spin. i.e. it no longer uses byte code but compiles directly to machine code.
Heck, you can't call C++ methods from C, How can we expect C to call Spin methods?
To make PASM written in Spin or C usable in either language, or other languages, it has to be decoupled from the HLL. It has to be more like those binary blobs of firmware that operating systems load into peripheral devices to make the run.
That means changing Spin a bit to impose some simple rules. like:
1) PASM sections should not rely on variables or constants defined in Spin
2) Spin code should not be allowed to "poke" values into the DAT section that will be loaded to COG at COG start (C programs won't know the addresses of those values.)
3) All parameters must be passed into PASM code via PAR at start up, i.e. not rely on those "pokes" above.
These ideas and techniques/rules for making PASM reusable across different language systems have been debated here for years. RossH even documented what it would take very nicely.
However I don't think Spin users would accept such rules being introduced to Spin.
So it's impossible.
However, it's totally possible. Again, a compelling body of code will present high use value. The higher that use value is, the more likely we get easily callable or easily modified to be callable programs we can add to that body of code.
Center of gravity working as it should.
Ah, "impossible", that magic word that get's thing done around here. Even before you have used it sometimes !
Actually I think I was confusing two issues in my "impossible" rant above.
1) Combining Spin and C in the same program. Or at least being able to call from one into another even if not both ways around. That seems to be what spinwrap does. I will have to look more at that.
2) Making PASM code universally usable across all languages as binary blobs no matter if it was written in a Spin object or in GAS or whatever. Does Spin wrap address that ?
I support David's efforts in SpinWrap, but he would acknowledge that this is not an optimal way to integrate PASM objects (as opposed to Spin objects).
It is too slow for some purposes, costs an unnecessary cog, and some unnecessary Hub RAM space. I'm not claiming Catalina's method is optimal, but it does everything SpinWrap does, and much more (e.g. locking, cog management etc).
And it is more efficient in both cog usage and hub ram usage.
Ross.
Yes.
I'm compiling the DE0-Nano now. I had to remove the PIX, CORDIC, CTRB, SERB, and waveform output from CTRA to get things to fit. If this compile works, I'll try putting the waveform output back in for CTRA. Anyway, you need the VID and XFR blocks to do multithreaded VGA w/SDRAM, and those blocks are both in the DE0-Nano compile. For the SDRAM writing/reading, you'll need to be single-tasking because that requires exact timing.
I think it's high time to update the monitor document.