Indexing is nice. If I'm seeing it right, the only negative effect would be trying to get a nibble or something from register#0, which would probably be a rare case...
incmod is nice instruction too. I'm so far behind with the new instructions...
Indexing is nice. If I'm seeing it right, the only negative effect would be trying to get a nibble or something from register#0, which would probably be a rare case...
incmod is nice instruction too. I'm so far behind with the new instructions...
Nibble, byte, and word accesses can be done from any base, even 0. You're not that far behind, don't worry. I know that a steady stream of changes have demoralized people somewhat, but the changes are getting fewer and tighter.
I'm guessing fact that you're now thinking about Spin2 is a good sign that you're about done.
Yes, I think the hardware is done, though some minor things may crop up during Spin2 development.
Hmmm... If "minor" changes are allowed to support better Spin2 performance maybe I should start on PropGCC in case a few other "minor" changes could improve its performance as well. :-)
I'm guessing fact that you're now thinking about Spin2 is a good sign that you're about done.
Yes, I think the hardware is done, though some minor things may crop up during Spin2 development.
Hmmm... If "minor" changes are allowed to support better Spin2 performance maybe I should start on PropGCC in case a few other "minor" changes could improve its performance as well. :-)
Yes, You may realize that something simple is missing that could help things out a lot, if it were to be implemented.
Hmmm... If "minor" changes are allowed to support better Spin2 performance maybe I should start on PropGCC in case a few other "minor" changes could improve its performance as well. :-)
I notice the smiley there, but this is a good idea - real test cases are needed to shake out all use instances.
The same applies to hardware like the streamer - as best I can tell, I think you can send small bursts and the buffering will manage a direction change, which in theory means HyperRAM would be one WR burst of command/address and then one of: another RD burst to read N bytes, or another WR burst to write N bytes..
HyperRAM can tolerate small gaps/pauses in the clocks, but the buffering may mean this auto-queues.
Little things like bus-contention may cause problems, and the only way to be sure, is to do real tests.
Hmmm... If "minor" changes are allowed to support better Spin2 performance maybe I should start on PropGCC in case a few other "minor" changes could improve its performance as well. :-)
That's a great idea! I would be glad to help out, and maybe we can get a few more volunteers to help with PropGCC for the P2.
Hmmm... If "minor" changes are allowed to support better Spin2 performance maybe I should start on PropGCC in case a few other "minor" changes could improve its performance as well. :-)
That's a great idea! I would be glad to help out, and maybe we can get a few more volunteers to help with PropGCC for the P2.
What I did last time I worked on a P2 code generator was to start with GAS to add all of the new instruction forms that weren't in P2. The first time around I just merged the P2 code into the P1 code. I don't think I'd do that this time. I'd probably keep them separate. It got a bit confusing with two processors merged into a single opcode table. In fact, the P2-hot code generator is still there. I guess my first step would be to extract it from the P1 module and adjust it to the new assembler syntax. Is there a description of the PNut assembler syntax somewhere?
.... I guess my first step would be to extract it from the P1 module and adjust it to the new assembler syntax. Is there a description of the PNut assembler syntax somewhere?
Another approach, rather smarter in the long term, would be to have PNut assembler morph more toward GAS. ( & fasmg)
This would allow GAS documentation on the web to stay valid for most cases, as well as make P2 Asm cleaner and easier to read.
GAS is generated by compilers too, so it is not just the ASM-read side that need modifying.
.... I guess my first step would be to extract it from the P1 module and adjust it to the new assembler syntax. Is there a description of the PNut assembler syntax somewhere?
Another approach, rather smarter in the long term, would be to have PNut assembler morph more toward GAS. ( & fasmg)
This would allow GAS documentation on the web to stay valid for most cases, as well as make P2 Asm cleaner and easier to read.
GAS is generated by compilers too, so it is not just the ASM-read side that need modifying.
I'm not sure GAS is the best model for a modern assembler.
I'm not sure GAS is the best model for a modern assembler.
Maybe not, but it does come with GCC, right, which rather makes GAS the default, for much the same reason C is a default. Sadly in the real world, 'Widely used and deployed' trumps 'best model' most times.
Personally, I like fasmg, which uses the more widespread semicolon ';' as a comment delimiter.
GAS allows target defined comments, so it can also support ;
I'm not sure GAS is the best model for a modern assembler.
Maybe not, but it does come with GCC, right, which rather makes GAS the default, for much the same reason C is a default. Sadly in the real world, 'Widely used and deployed' trumps 'best model' most times.
Personally, I like fasmg, which uses the more widespread semicolon ';' as a comment delimiter.
GAS allows target defined comments, so it can also support ;
Okay, I'm waiting to see the reaction when you try to convince Chip to adopt GAS syntax. :-)
Okay, I'm waiting to see the reaction when you try to convince Chip to adopt GAS syntax. :-)
I'm happy to make a case for that, as above.
PNut does not need to clone all of GAS syntax, just move sideways enough to avoid conflicts.
ie become a co-operative subset of GAS.
Is PNut still coded in Assembler, or is it coded in Delphi, which I think Chip also uses ?
Okay, I'm waiting to see the reaction when you try to convince Chip to adopt GAS syntax. :-)
I'm happy to make a case for that, as above.
PNut does not need to clone all of GAS syntax, just move sideways enough to avoid conflicts.
ie become a co-operative subset of GAS.
Is PNut still coded in Assembler, or is it coded in Delphi, which I think Chip also uses ?
Ah, I guess that's why, on WINE, PX works and PNut doesn't. PX is 100% Delphi.
A problem right there, but I'm not sure that is fundamental in using ASM per-se, is it ?
Can you try fasmw and fasmg(win) under WINE, and see if they work ?
(they are both self-building ie written in assembler)
But why do a byte code interpreter at all? Why not just go directly to a native compiler?
Without good optimization, a native compiler will make big code. The byte code starts out optimized. Plus, habit, I guess.
Even moderate optimization can produce reasonable code. Have you looked at fastspin, Chip? Its optimizer is of middling quality (nowhere near what GCC does, for example) yet the code it produces is, I think, decent. Sizes of binaries are not bad, after inlining and dead code removal. For example, the S3 Scribbler "bp_test" program has the following compiled sizes:
In this case fastspin actually produces smaller binaries (compiling to PASM) than the "regular" bytecode compiler does! Most of that difference is due to removal of unused functions, as we see when looking at the (optimized) bstc result. Still, it's not actually as much overhead as one might think.
fastspin/spin2cpp is open source (MIT) so you certainly could re-use any parts of it that are of interest to you, and I'd be happy to help with that.
Eric
Regarding Spin2...
Eric,
I think you have all the keys needed to make Spin2.
I've been looking over the work I did on it, but abandoned in 2013 to get back to the hardware, and I'll need more time just to mentally spool up, again, before I'll even know HOW to think about it.
Roy Eltham has done a lot of work on Spin tools, too, and he's around your level. There are probably others here, too.
I wish I had a vision of how we could all collaborate to define the language. It really doesn't need to be that complicated, but parsing all the ideas seems complicated, at the moment. Any of us could go make our own whole language as quickly as we could work together, maybe even quicker. Do you think it's likely, though, that we could openly collaborate on the language definition and get something that's more robust and could be built easily?
These are a few things that are on my mind:
- maybe floating point support built in, somehow
- structures, maybe
- a base Spin language that is not overly tied to the hardware. See the instruction spreadsheet with the Spin procedures for PASM instructions - they provide a bridge to the actual instructions without Spin needing to absorb and repackage everything. This lightens up Spin and encourages PASM programming.
- native code output, at least as an option
- method pointers
- methods can return any number of parameters
- dead code removal (at least unused methods)
Really, Spin2 just needs to be about scope, math/logic, and flow control. It doesn't need to deal with the streamer or anything too specific. It just needs to be a framework for writing code and incorporating objects.
I think you have all the keys needed to make Spin2.
I've been looking over the work I did on it, but abandoned in 2013 to get back to the hardware, and I'll need more time just to mentally spool up, again, before I'll even know HOW to think about it.
Roy Eltham has done a lot of work on Spin tools, too, and he's around your level. There are probably others here, too.
I wish I had a vision of how we could all collaborate to define the language. It really doesn't need to be that complicated, but parsing all the ideas seems complicated, at the moment. Any of us could go make our own whole language as quickly as we could work together, maybe even quicker. Do you think it's likely, though, that we could openly collaborate on the language definition and get something that's more robust and could be built easily?
- maybe floating point support built in, somehow
- structures, maybe
- a base Spin language that is not overly tied to the hardware. See the instruction spreadsheet with the Spin procedures for PASM instructions - they provide a bridge to the actual instructions without Spin needing to absorb and repackage everything. This lightens up Spin and encourages PASM programming.
- native code output, at least as an option
- method pointers
- methods can return any number of parameters
- dead code removal (at least unused methods)
I think here you mean both byte-code and native-code output compilation ?
Scripts often limit the supported types (unlike C) in order to simplify the user side, but that has a size and speed cost, that is likely too high on a microcontroller.
A key question then becomes, exactly what types does Spin-2 support ?
float would be important, as C has that already, and you would want Spin-2 <-> C calling, right ?
uint32_t - seems natural starting point
uint64_t,int64_t ? maybe needed for maths results ?
uint8_t because opcodes support byte, and so many peripherals are byte based.
uint4_t - does this make sense with new opcodes ?
bit ? - with opcodes to access pins, this is more natural (a la 8051's named boolean variables)
Ah, I guess that's why, on WINE, PX works and PNut doesn't. PX is 100% Delphi.
A problem right there, but I'm not sure that is fundamental in using ASM per-se, is it ?
I wasn't trying to say that. PNut almost works. It toggles the DTR line too much is all. The negotiations are fine and data all flows but the Prop2 doesn't see the start of the program data because of the extra DTR resets. There is some tiny procedural issue that is doing it different enough, compared to PX, to upset Wine's handling of the comport. Presumably it's an old piece of assembly that goes way back.
Notably PNut doesn't run on Win98 either. Looks like it may need Win2k or even WinXP as a minimum.
Pnut is a mix of delphi and x86. The delphi part is mainly the GUI and text editor stuff. The Spin/PASM compiler/assembler stuff is all x86. This was true for P1 and P2-hot, and this P2 variant as well.
I think Spin2 needs to have method pointers and structures for sure. I would like some ambiguities and oddities fixed also. Like there are cases where constants from included objects can't be used where they should, etc.
If it supports inline PASM, then can't all the P2 specific things just be done via that? Maybe I'm missing something?
I think it should also support I2C, SPI, and simple Serial built in, as well as floating point. Any other simple protocols that can be made into builtin methods should be there. These are things that make it easy to use for many applications, and easy for education. It's all trivial to have there if used and excluded if not, especially with hubexec. It will also make it nice for marketing bullet points, since it supports all those things without any caveats (on p1 you have to find and include the proper objects and start them up, etc.).
Also, jmg, I am strongly against making PASM more like GAS. PASM is a joy to program in, GAS is dreadful. Just make something to translate from PASM to GAS or vice versa if you really need it.
Comments
incmod is nice instruction too. I'm so far behind with the new instructions...
Nibble, byte, and word accesses can be done from any base, even 0. You're not that far behind, don't worry. I know that a steady stream of changes have demoralized people somewhat, but the changes are getting fewer and tighter.
Yes, I think the hardware is done, though some minor things may crop up during Spin2 development.
Yes, You may realize that something simple is missing that could help things out a lot, if it were to be implemented.
The same applies to hardware like the streamer - as best I can tell, I think you can send small bursts and the buffering will manage a direction change, which in theory means HyperRAM would be one WR burst of command/address and then one of: another RD burst to read N bytes, or another WR burst to write N bytes..
HyperRAM can tolerate small gaps/pauses in the clocks, but the buffering may mean this auto-queues.
Little things like bus-contention may cause problems, and the only way to be sure, is to do real tests.
Another approach, rather smarter in the long term, would be to have PNut assembler morph more toward GAS. ( & fasmg)
This would allow GAS documentation on the web to stay valid for most cases, as well as make P2 Asm cleaner and easier to read.
GAS is generated by compilers too, so it is not just the ASM-read side that need modifying.
Maybe not, but it does come with GCC, right, which rather makes GAS the default, for much the same reason C is a default. Sadly in the real world, 'Widely used and deployed' trumps 'best model' most times.
Personally, I like fasmg, which uses the more widespread semicolon ';' as a comment delimiter.
GAS allows target defined comments, so it can also support ;
PNut does not need to clone all of GAS syntax, just move sideways enough to avoid conflicts.
ie become a co-operative subset of GAS.
Is PNut still coded in Assembler, or is it coded in Delphi, which I think Chip also uses ?
Can you try fasmw and fasmg(win) under WINE, and see if they work ?
(they are both self-building ie written in assembler)
Regarding Spin2...
Eric,
I think you have all the keys needed to make Spin2.
I've been looking over the work I did on it, but abandoned in 2013 to get back to the hardware, and I'll need more time just to mentally spool up, again, before I'll even know HOW to think about it.
Roy Eltham has done a lot of work on Spin tools, too, and he's around your level. There are probably others here, too.
I wish I had a vision of how we could all collaborate to define the language. It really doesn't need to be that complicated, but parsing all the ideas seems complicated, at the moment. Any of us could go make our own whole language as quickly as we could work together, maybe even quicker. Do you think it's likely, though, that we could openly collaborate on the language definition and get something that's more robust and could be built easily?
These are a few things that are on my mind:
- maybe floating point support built in, somehow
- structures, maybe
- a base Spin language that is not overly tied to the hardware. See the instruction spreadsheet with the Spin procedures for PASM instructions - they provide a bridge to the actual instructions without Spin needing to absorb and repackage everything. This lightens up Spin and encourages PASM programming.
- native code output, at least as an option
- method pointers
- methods can return any number of parameters
- dead code removal (at least unused methods)
Really, Spin2 just needs to be about scope, math/logic, and flow control. It doesn't need to deal with the streamer or anything too specific. It just needs to be a framework for writing code and incorporating objects.
I think Eric codes using C/C++.
What did you use to code earlier Spin-2 in ?
I think here you mean both byte-code and native-code output compilation ?
Scripts often limit the supported types (unlike C) in order to simplify the user side, but that has a size and speed cost, that is likely too high on a microcontroller.
A key question then becomes, exactly what types does Spin-2 support ?
float would be important, as C has that already, and you would want Spin-2 <-> C calling, right ?
uint32_t - seems natural starting point
uint64_t,int64_t ? maybe needed for maths results ?
uint8_t because opcodes support byte, and so many peripherals are byte based.
uint4_t - does this make sense with new opcodes ?
bit ? - with opcodes to access pins, this is more natural (a la 8051's named boolean variables)
Notably PNut doesn't run on Win98 either. Looks like it may need Win2k or even WinXP as a minimum.
I think Spin2 needs to have method pointers and structures for sure. I would like some ambiguities and oddities fixed also. Like there are cases where constants from included objects can't be used where they should, etc.
If it supports inline PASM, then can't all the P2 specific things just be done via that? Maybe I'm missing something?
I think it should also support I2C, SPI, and simple Serial built in, as well as floating point. Any other simple protocols that can be made into builtin methods should be there. These are things that make it easy to use for many applications, and easy for education. It's all trivial to have there if used and excluded if not, especially with hubexec. It will also make it nice for marketing bullet points, since it supports all those things without any caveats (on p1 you have to find and include the proper objects and start them up, etc.).
Also, jmg, I am strongly against making PASM more like GAS. PASM is a joy to program in, GAS is dreadful. Just make something to translate from PASM to GAS or vice versa if you really need it.
I'm sure it's brilliant. Small, fast, flexible and all that.
But it's written in x86 assembler! Totally not portable. Ultimately a dead end.