The operators are not the only problem with Spin. I'd say they are a rather minor part. The main problem is that it is a totally unfamiliar language for nearly everyone who might consider the Propeller.
Perhaps, but the operators are what serves to make it "a totally unfamiliar language".
eg Spin has keywords like
IF
IFNOT
CASE
REPEAT
NEXT
QUIT
RETURN
and anyone can reasonably guess what any of those are, and improve that guess if seeing them in context.
That is not true with the operators, which mandate a look-at-the-manual, ( whilst mumbling WTF?)
That is certainly true. I always have to look up unfamiliar ones.
I am extremely against having a pragma change the syntax of the language on a file by file basis. That's complete and utter horseshit.
The language should be one thing, and if people want to use defines/macros to do something else, then fine. Those people will be shunned anyway, because changing language syntax from file to file is complete and utter horseshit!
It's something we shouldn't even be thinking about let alone discussing. Have I mentioned that it's complete and utter horseshit, yet?
Seriously guys, Spin2 does not have to be 100% compatible with Spin1 (it can't be). It has a lot of similarities, and that should be enough. Besides I'm sure someone like Cluso will make a Spin1 runtime emulation for P2 if they really truly want it (good luck to them on timers and whatnot).
In any case, changing language syntax with a per file pragma is just complete and utter horseshit!
I am extremely against having a pragma change the syntax of the language on a file by file basis. That's complete and utter horseshit.
...but is both tried and proven, over decades, & just like horseshit = proven to give better harvests !!
Even the C camp have used define and ifdef as user pragmas for decades...
( I see Google of #ifdef __cplusplus gives ~ 1,540,000 results, {$Mode Delphi} gives 1,280,000 results )
Tip: The real use determines these things, not words in some forum.
I am extremely against having a pragma change the syntax of the language on a file by file basis. That's complete and utter horseshit.
The language should be one thing, and if people want to use defines/macros to do something else, then fine. Those people will be shunned anyway, because changing language syntax from file to file is complete and utter horseshit!
It's something we shouldn't even be thinking about let alone discussing. Have I mentioned that it's complete and utter horseshit, yet?
Seriously guys, Spin2 does not have to be 100% compatible with Spin1 (it can't be). It has a lot of similarities, and that should be enough. Besides I'm sure someone like Cluso will make a Spin1 runtime emulation for P2 if they really truly want it (good luck to them on timers and whatnot).
In any case, changing language syntax with a per file pragma is just complete and utter horseshit!
I don't like the idea, either. We'll make it one way, whatever seems best, and that will be that. Did you get a horse, or something? Beau Schwabe got a race horse. I wonder if he's got a flat rock in the corral.
jmg, the use cases in C/C++ are not the same thing as what's being suggested here, and you know it. Besides with the preprocessor you will be able to do the same things as C/C++ does, no need to have a single pragma change the syntax of the language, which is NOT what you are finding with your searches.
Chip, no, but I was trying to not use much harsher language which is what I defaulted to using at this repulsive idea.
...but I was trying to not use much harsher language which is what I defaulted to using at this repulsive idea.
So you keep chanting, but the real world out there seems quite comfortable with language variances, target variances, evolution and user control ?
Do you have anything more concrete and rational than "horseshit" and "repulsive" as I don't think that's helping your cause ?
Languages evolve, sure, but generally maintain backward compatibility, and I have yet to encounter one that supports completely different sets of operators given a pragma or compiler setting.
Also, Roy - don't hold back, it's bad to bottle stuff up. Tell us how you really feel.
Languages evolve, sure, but generally maintain backward compatibility, and I have yet to encounter one that supports completely different sets of operators given a pragma or compiler setting.
Nor is that being proposed here.
A pragma/compiler setting is only needed when a conflict arises.
Looks like Chip is prepared to avoid the worst conflicts, so a pragma may be entirely avoidable.
Again, drawing on a real example, this is what FreePascal does - gives users a choice
shl Bitwise shift left
shr Bitwise shift right
<< Bitwise shift left
>> Bitwise shift right
I like SPIN. It reads well with its IF/CASE/REPEAT/NEXT/QUIT/RETURN keywords. And using indentation to indicate blocks is as good and clear a way as any. And regarding the keywords....
anyone can reasonably guess what any of those are, and improve that guess if seeing them in context.
Absolutely right!
But the operators trip people up, namely the people on this forum. So SPIN just needs a bit of an overhaul to harmonize the operators with existing conventions. SPIN will still be SPIN.
While (okay...if) making such changes, I wonder if the way TRUE is done is ideal. That seems to trip me up, but I can also live with it as is.
I love the REPEAT loop variations. But one thing I don't like is how if you enter a loop with the end starting value greater than the starting ending value, the loop counts backwards automatically without explicitly requiring that, instead of skipping the loop entirely like some languages do. That has forced me to stop and think and rewrite on occasion. It seems TOO CLEVER to me; that is, I think it would be better to explicitly specify a negative step. I think that would further harmonize SPIN with other languages while still keeping the flavor and friendly keywords of SPIN. I know that's off the operator topic, but I thought it was worth mentioning. <About the forgoing, it seems I'm out of date>
Anyway, I'm happy to see the progress being made on the SPIN interpreter, and the willingness to at least consider making some small changes. If changes are going to be made, THE TIME IS NOW. Let's not saddle the P2 just to be more backwards compatible. I have a couple dozen programs I may have to port over and some adjustments will be needed. That's just the way it is and I don't mind. It's worth it for future sanity and smoothness, and it will help newcomers embrace SPIN as a language for the new chip (along with whatever else is available).
JasonDorie,
If you get to know me, you'll find that I generally don't hold back or bottle things up ever. It gets me in trouble at work often enough, but never much trouble, because most bossed prefer the truth than wishy washy softness.
jmg,
You have yet to show a language that does the extreme of what is proposed here? Like I said, with the preprocessor, people will be able to do whatever they can in C (or other languages) in Spin, No need to add the proposed pragma to change how the source is parsed for operators/etc.
You have yet to show a language that does the extreme of what is proposed here?
That's because I have no idea what you imagine to be "the extreme of what is proposed here" ?
All I can do, is show examples of what the real world does now, and how they manage evolution and differences in languages and targets, whilst keeping code maintainable.
I do not see anything extreme, just plain old boring common sense.
But the operators trip people up, namely the people on this forum. So SPIN just needs a bit of an overhaul to harmonize the operators with existing conventions. SPIN will still be SPIN.
I love the REPEAT loop variations. But one thing I don't like is how if you enter a loop with the end value greater than the starting value, the loop counts backwards automatically without explicitly requiring that, instead of skipping the loop entirely like some languages do. That has forced me to stop and think and rewrite on occasion. It seems TOO CLEVER to me; that is, I think it would be better to explicitly specify a negative step. I think that would further harmonize SPIN with other languages while still keeping the flavor and friendly keywords of SPIN. I know that's off the operator topic, but I thought it was worth mentioning.
Certainly, being able to sweep both ways is now widespread, and also common in a FOR .. IN .. that scans all elements in an already known subrange.
Anyway, I'm happy to see the progress being made on the SPIN interpreter, and the willingness to at least consider making some small changes. If changes are going to be made, THE TIME IS NOW. Let's not saddle the P2 just to be more backwards compatible. I have a couple dozen programs I may have to port over and some adjustments will be needed. That's just the way it is and I don't mind. It's worth it for future sanity and smoothness, and it will help newcomers embrace SPIN as a language for the new chip (along with whatever else is available).
@jmg: Thanks for the responses. Maybe the difficulties I've had with true/false on occasion were due to my faulty assumptions, so I don't think I'll try to detail it at this time and I struck out my comment. As for loop sweeping directions, perhaps I'm behind the times there.
You know, what I'd really, really, really like in SPIN2 would be arrays of arrays (yeah, that could be another thread). I need to use arrays of arrays all the time, but I always have to use somewhat ugly or awkward multipliers as offsets to the base addresses. However, it's likely that I need arrays of arrays more than the average person working on a microcontroller due to the nature of my main application. For example, I often need to access multiple sets of fixed-length strings, wherein the strings at the same level in each set are related somehow. Hence, it would be nice to specify something like s[setNo][stringNo]. I don't mean exactly that syntax, as that may collide with existing syntax, but something equivalent that avoids having to use a multiplier for the length of the strings, maybe in the s[setNo, stringNo] style or perhaps with some other kind of brackets. This situation is very common for me. I don't seem to need more than a couple dimensions of arrays, though, if that would make implementing this easier. Avoiding the multipliers would make my code easier to read (of course, we can't avoid multipliers entirely in programming, I realize). Yeah, maybe I should be working in a form of BASIC, but I like SPIN and it's basically a native language on the P1 and it's quite compact. Anyway, I'd sure be a happy camper with arrays of arrays. I guess I could use functions, but it slows things down. Then again, SPIN2 will be faster, but there's still the readability thing, and it's easier to make mistakes when using multipliers, such as leaving them off inadvertently.
@jmg: Thanks for the responses. Maybe the difficulties I've had with true/false on occasion were due to my faulty assumptions, so I don't think I'll try to detail it at this time and I struck out my comment.
That seems related to a test being more accurately NOT FALSE, whilst a pre-defined 'TRUE' is not the same across 8b.16b.32b entities. Looks like a cleanup could help there ?
@jmg: About, true/false, I vaguely recall being bitten (more likely by myself) a couple times, but I do remember reading that page you linked with interest a while back (I read all the "gotcha" pages since they have my name on them).
As for loops, I knew that you were referring to other languages. But it's been quite some time since I've done programming in C/C++ or Java, so I didn't elaborate. But I seem to recall loops being skipped entirely if the starting value was higher than the ending value (sorry, I said that backwards in my original post), which I've relied on before in other languages. But I need to restructure things a bit for SPIN. It's likely the case that I'm just not used to it. Overall, I love SPIN loops. And maybe I should love that flexibility, too. And obviously a good case could be made for the loops automatically selecting the direction such that one doesn't need to add extra logic to do that. Sorry that I brought it up.
As for For..In loops (or similar keywords), I've used those in JavaScript in the past and they made perfect sense, as one was just iterating through all the elements in a set (in whatever order the system gave them to you). That's a cool construct. But in my post, I was talking about starting and ending values with relative magnitudes (and hence a specific, predictable direction of travel, so to speak).
Anyway, speaking of old threads, I do recall reading one about people being confused on the way that REPEAT loops work when the end value is less than the starting value, so I'm not the only one that has been caught off guard before. But, again, I think I just need to adjust my thinking a slight tad (purposefully redundant). I'm okay with the way SPIN loops work (and mostly love them overall; they are one of the reasons I like SPIN); I just mentioned the matter because I knew that I and others had used them improperly before. So I just brought them up in my post in case they were more problematic for people than I realized, you know, in that changes are under discussion now. But it's probably best to keep the loops the way they are, unlike the case with the operators, I feel, as the current operators definitely differ from the expectations of so many. For example, almost every time I want to create a "greater than or equal" comparison, I practically have to force myself to say "equal or greater" aloud as I've seen Chip spell out.
Put me in the no modals column. That's a state people must remember and maintain.
Regarding C, Chip will do SPIN, PASM and the P2 as one unified design. The moment the chip goes to synthesis, perhaps sooner, real work on C can begin.
At release, or formal release after shuttle run chips, we are likely to have both available.
SPIN needs to be the unified thing it is. Some tweaks are good, but having it be unified with PASM and the P2 itself is a big deal. Anyone who dips their toe in us likely to get the benefits.
Making SPIN like other things runs the risk of diluting those benefits and does not make sense given other tools can and will be made available.
Regarding C, Chip will do SPIN, PASM and the P2 as one unified design. The moment the chip goes to synthesis, perhaps sooner, real work on C can begin.
That's the concern I have with C. It's treated as an afterthought. Ideally, C, Spin, PASM and the P2 should be one unified design. This is especially important since many people may not even use the Spin interpreter to run Spin. They can convert Spin to C or even compile Spin directly to PASM. And many people will not use Spin at all, but program only in C.
I'm not suggesting that Chip needs to work on the C compiler. That is better left for the GCC gurus that did the PropGCC implementation on the P1. What I am suggesting is that Parallax kick off a PropGCC effort for the P2, with paid consultants like they did for P1. To be honest, I think it is very late in the game to do this on the P2, but there's no time like the present to get started. Given the current state of the P2 development, we probably got another year or two before we see silicon.
Is there more needed? I think that question will only be answered by running lots of C code to see how it performs. Most C applications will run in hub exec mode. I don't think we've really tested hub exec enough to know if there are any issues that might have simple fixes. It will be too late to make any fixes if C isn't available until after the chip goes into synthesis.
Two things I can think of that would be useful for C:
(1) A "base + offset" addressing mode, similar to the PTRA[INDEX] mode but for any registers and with a fairly large possible offset (ideally 20 bits). Maybe ALTI can already do this, but if so I've missed it in the docs. It'd be OK if offset has to be an immediate, and I would expect that we would need an ALTxx prefix of some sort on the instruction to make this work. The PTRx addressing modes are great, but (a) we only have two PTR registers, one of which will probably be reserved for stack, and (b) the available offsets are fairly limited, I think.
(2) A compressed instruction mode. This one probably is too late, but many architectures have a 16 bit subset that can expand out to the full 32 bit instructions (like THUMB for ARM or RV32C for RISC-V). The C compiler is likely to heavily use a relatively small set of 16 or 32 registers, very few instructions other than branches will be conditional, and just a few instructions (like MOV, ADD, JMP, CMP) will occur frequently. So there's lots of room to compress the instruction stream. This would only make sense in HUBEXEC, of course, but it woud allow us to put a lot more code into HUB. Catalina and PropGCC both came up with compressed schemes for P1, and they both performed pretty well.
(2) A compressed instruction mode. This one probably is too late, but many architectures have a 16 bit subset that can expand out to the full 32 bit instructions (like THUMB for ARM or RV32C for RISC-V). The C compiler is likely to heavily use a relatively small set of 16 or 32 registers, very few instructions other than branches will be conditional, and just a few instructions (like MOV, ADD, JMP, CMP) will occur frequently. So there's lots of room to compress the instruction stream.
An alternative to that, would be better XIP support, as expanding off-chip is more practical in 2017, then it was in P1's day. Such memory is cheap, small, uses few pins, and can expand WAY above the P2's memory ceiling.
The core of the streamer looks to be able to handle the main data flows, and some kludged DDR is possible, but more native DDR could make sense ?
It may be the new tight-loop support, can allow a dedicated COG to SW manage XIP, but ideally this should be tested and verified.
Two things I can think of that would be useful for C:
(1) A "base + offset" addressing mode, similar to the PTRA[INDEX] mode but for any registers and with a fairly large possible offset (ideally 20 bits). Maybe ALTI can already do this, but if so I've missed it in the docs. It'd be OK if offset has to be an immediate, and I would expect that we would need an ALTxx prefix of some sort on the instruction to make this work. The PTRx addressing modes are great, but (a) we only have two PTR registers, one of which will probably be reserved for stack, and (b) the available offsets are fairly limited, I think.
(2) A compressed instruction mode. This one probably is too late, but many architectures have a 16 bit subset that can expand out to the full 32 bit instructions (like THUMB for ARM or RV32C for RISC-V). The C compiler is likely to heavily use a relatively small set of 16 or 32 registers, very few instructions other than branches will be conditional, and just a few instructions (like MOV, ADD, JMP, CMP) will occur frequently. So there's lots of room to compress the instruction stream. This would only make sense in HUBEXEC, of course, but it woud allow us to put a lot more code into HUB. Catalina and PropGCC both came up with compressed schemes for P1, and they both performed pretty well.
I don't know that a special ALTxx instruction would be any more efficient than:
LOC PA,#base20
ADD PA,index
JMP PA
Because addressing deals with 20-bit values, you'll need LOC to supply the base address.
(2) A compressed instruction mode. This one probably is too late, but many architectures have a 16 bit subset that can expand out to the full 32 bit instructions (like THUMB for ARM or RV32C for RISC-V). The C compiler is likely to heavily use a relatively small set of 16 or 32 registers, very few instructions other than branches will be conditional, and just a few instructions (like MOV, ADD, JMP, CMP) will occur frequently. So there's lots of room to compress the instruction stream.
An alternative to that, would be better XIP support, as expanding off-chip is more practical in 2017, then it was in P1's day. Such memory is cheap, small, uses few pins, and can expand WAY above the P2's memory ceiling.
The core of the streamer looks to be able to handle the main data flows, and some kludged DDR is possible, but more native DDR could make sense ?
It may be the new tight-loop support, can allow a dedicated COG to SW manage XIP, but ideally this should be tested and verified.
One thing I've never understood about your interest in XIP is that an XIP-friendly memory chip would only work for one cog. I think you must be envisioning one central program running on one cog, with the other cogs doing smaller things.
I don't know that an ALTxx instruction would be any more efficient than using:
LOC PA,#base20
ADD PA,index
JMP PA
Because this deals with 20-bit constants, and not 9-bit constants, you need LOC to supply the address.
I guess I didn't explain it well, I was referring to data read/write (e.g. from offsets in a structure) rather than branches. So what I'd like would be a more efficient way of doing:
mov temp, basereg
add temp, #imm_offset ' or even better ##imm_offset
wrlong data, temp
This is pretty similar to
wrlong data,PTRA[imm_offset]
but without requiring one of the PTRx registers (and without necessarily scaling the immediate offset). There are already some data paths there for handling PTRA/PTRB, I'm just wondering how hard it would be to (a) substitute another register as the source, and/or (b) allow the imm_offset to be extended.
This kind of pattern is pretty common. In fastspin I had it do
add basereg, #imm_offset ' or even better ##imm_offset
wrlong data, basereg
sub basereg, #imm_offset ' restore original value of basereg
and then later try to merge adjacent add/sub pairs, but obviously that isn't always possible.
One thing I've never understood about your interest in XIP is that an XIP-friendly memory chip would only work for one cog. I think you must be envisioning one central program running on one cog, with the other cogs doing smaller things.
There is nothing technically stopping more than one COG from reaching into XIP memory, except that would thrash the bus more, and increase latencies. In some cases, that could be tolerable.
Usually the 'main code' would run on a single P2 COG, as it will follow other MCU models.
Users can, and will, pull out 'driver level like' functions to run on other COGS. Some of those may creep into HUB space, but the general nature is they would be loaded and run without being moved.
XIP allows the 'main code' to place most often used functions in HUB, and then call into further memory, where the usual size-speed trade-offs apply. Code like POST, or Setup menus, are some examples of not-used-often, but still required to be available code.
I don't know that an ALTxx instruction would be any more efficient than using:
LOC PA,#base20
ADD PA,index
JMP PA
Because this deals with 20-bit constants, and not 9-bit constants, you need LOC to supply the address.
I guess I didn't explain it well, I was referring to data read/write (e.g. from offsets in a structure) rather than branches. So what I'd like would be a more efficient way of doing:
mov temp, basereg
add temp, #imm_offset ' or even better ##imm_offset
wrlong data, temp
This is pretty similar to
wrlong data,PTRA[imm_offset]
but without requiring one of the PTRx registers (and without necessarily scaling the immediate offset). There are already some data paths there for handling PTRA/PTRB, I'm just wondering how hard it would be to (a) substitute another register as the source, and/or (b) allow the imm_offset to be extended.
This kind of pattern is pretty common. In fastspin I had it do
add basereg, #imm_offset ' or even better ##imm_offset
wrlong data, basereg
sub basereg, #imm_offset ' restore original value of basereg
and then later try to merge adjacent add/sub pairs, but obviously that isn't always possible.
I see.
You could do this:
LOC PA,#\imm20offset 'use "\" to force absolute value
ADD PA,basereg
WRLONG data,PA
No cleanup needed, then. (Wait... That's three instructions, not two.)
Comments
The language should be one thing, and if people want to use defines/macros to do something else, then fine. Those people will be shunned anyway, because changing language syntax from file to file is complete and utter horseshit!
It's something we shouldn't even be thinking about let alone discussing. Have I mentioned that it's complete and utter horseshit, yet?
Seriously guys, Spin2 does not have to be 100% compatible with Spin1 (it can't be). It has a lot of similarities, and that should be enough. Besides I'm sure someone like Cluso will make a Spin1 runtime emulation for P2 if they really truly want it (good luck to them on timers and whatnot).
In any case, changing language syntax with a per file pragma is just complete and utter horseshit!
Even the C camp have used define and ifdef as user pragmas for decades...
( I see Google of #ifdef __cplusplus gives ~ 1,540,000 results, {$Mode Delphi} gives 1,280,000 results )
Tip: The real use determines these things, not words in some forum.
I don't like the idea, either. We'll make it one way, whatever seems best, and that will be that. Did you get a horse, or something? Beau Schwabe got a race horse. I wonder if he's got a flat rock in the corral.
Chip, no, but I was trying to not use much harsher language which is what I defaulted to using at this repulsive idea.
Do you have anything more concrete and rational than "horseshit" and "repulsive" as I don't think that's helping your cause ?
Also, Roy - don't hold back, it's bad to bottle stuff up. Tell us how you really feel.
A pragma/compiler setting is only needed when a conflict arises.
Looks like Chip is prepared to avoid the worst conflicts, so a pragma may be entirely avoidable.
Again, drawing on a real example, this is what FreePascal does - gives users a choice
shl Bitwise shift left
shr Bitwise shift right
<< Bitwise shift left
>> Bitwise shift right
Absolutely right!
But the operators trip people up, namely the people on this forum. So SPIN just needs a bit of an overhaul to harmonize the operators with existing conventions. SPIN will still be SPIN.
While (okay...if) making such changes, I wonder if the way TRUE is done is ideal. That seems to trip me up, but I can also live with it as is.
I love the REPEAT loop variations. But one thing I don't like is how if you enter a loop with the end starting value greater than the starting ending value, the loop counts backwards automatically without explicitly requiring that, instead of skipping the loop entirely like some languages do. That has forced me to stop and think and rewrite on occasion. It seems TOO CLEVER to me; that is, I think it would be better to explicitly specify a negative step. I think that would further harmonize SPIN with other languages while still keeping the flavor and friendly keywords of SPIN. I know that's off the operator topic, but I thought it was worth mentioning. <About the forgoing, it seems I'm out of date>
Anyway, I'm happy to see the progress being made on the SPIN interpreter, and the willingness to at least consider making some small changes. If changes are going to be made, THE TIME IS NOW. Let's not saddle the P2 just to be more backwards compatible. I have a couple dozen programs I may have to port over and some adjustments will be needed. That's just the way it is and I don't mind. It's worth it for future sanity and smoothness, and it will help newcomers embrace SPIN as a language for the new chip (along with whatever else is available).
If you get to know me, you'll find that I generally don't hold back or bottle things up ever. It gets me in trouble at work often enough, but never much trouble, because most bossed prefer the truth than wishy washy softness.
jmg,
You have yet to show a language that does the extreme of what is proposed here? Like I said, with the preprocessor, people will be able to do whatever they can in C (or other languages) in Spin, No need to add the proposed pragma to change how the source is parsed for operators/etc.
All I can do, is show examples of what the real world does now, and how they manage evolution and differences in languages and targets, whilst keeping code maintainable.
I do not see anything extreme, just plain old boring common sense.
I guess you didn't read the rest of the line, then?
What are the specific changes you want there ?
Certainly, being able to sweep both ways is now widespread, and also common in a FOR .. IN .. that scans all elements in an already known subrange.
Agreed.
For the record, I'm in complete agreement with you on this, I just thought your expression of it was funny.
I figured as much. I know you agree, because it makes sense, right? We have very similar backgrounds on coding I assume.
You know, what I'd really, really, really like in SPIN2 would be arrays of arrays (yeah, that could be another thread). I need to use arrays of arrays all the time, but I always have to use somewhat ugly or awkward multipliers as offsets to the base addresses. However, it's likely that I need arrays of arrays more than the average person working on a microcontroller due to the nature of my main application. For example, I often need to access multiple sets of fixed-length strings, wherein the strings at the same level in each set are related somehow. Hence, it would be nice to specify something like s[setNo][stringNo]. I don't mean exactly that syntax, as that may collide with existing syntax, but something equivalent that avoids having to use a multiplier for the length of the strings, maybe in the s[setNo, stringNo] style or perhaps with some other kind of brackets. This situation is very common for me. I don't seem to need more than a couple dimensions of arrays, though, if that would make implementing this easier. Avoiding the multipliers would make my code easier to read (of course, we can't avoid multipliers entirely in programming, I realize). Yeah, maybe I should be working in a form of BASIC, but I like SPIN and it's basically a native language on the P1 and it's quite compact. Anyway, I'd sure be a happy camper with arrays of arrays. I guess I could use functions, but it slows things down. Then again, SPIN2 will be faster, but there's still the readability thing, and it's easier to make mistakes when using multipliers, such as leaving them off inadvertently.
Was it related to this discussion ?
https://forums.parallax.com/discussion/165798/spin-a-byte-or-word-can-never-equal-1-and-true
That seems related to a test being more accurately NOT FALSE, whilst a pre-defined 'TRUE' is not the same across 8b.16b.32b entities. Looks like a cleanup could help there ?
I was meaning for other languages in general, not Spin.
As for loops, I knew that you were referring to other languages. But it's been quite some time since I've done programming in C/C++ or Java, so I didn't elaborate. But I seem to recall loops being skipped entirely if the starting value was higher than the ending value (sorry, I said that backwards in my original post), which I've relied on before in other languages. But I need to restructure things a bit for SPIN. It's likely the case that I'm just not used to it. Overall, I love SPIN loops. And maybe I should love that flexibility, too. And obviously a good case could be made for the loops automatically selecting the direction such that one doesn't need to add extra logic to do that. Sorry that I brought it up.
As for For..In loops (or similar keywords), I've used those in JavaScript in the past and they made perfect sense, as one was just iterating through all the elements in a set (in whatever order the system gave them to you). That's a cool construct. But in my post, I was talking about starting and ending values with relative magnitudes (and hence a specific, predictable direction of travel, so to speak).
Anyway, speaking of old threads, I do recall reading one about people being confused on the way that REPEAT loops work when the end value is less than the starting value, so I'm not the only one that has been caught off guard before. But, again, I think I just need to adjust my thinking a slight tad (purposefully redundant). I'm okay with the way SPIN loops work (and mostly love them overall; they are one of the reasons I like SPIN); I just mentioned the matter because I knew that I and others had used them improperly before. So I just brought them up in my post in case they were more problematic for people than I realized, you know, in that changes are under discussion now. But it's probably best to keep the loops the way they are, unlike the case with the operators, I feel, as the current operators definitely differ from the expectations of so many. For example, almost every time I want to create a "greater than or equal" comparison, I practically have to force myself to say "equal or greater" aloud as I've seen Chip spell out.
Now about those multi-dimensional arrays....
Put me in the no modals column. That's a state people must remember and maintain.
Regarding C, Chip will do SPIN, PASM and the P2 as one unified design. The moment the chip goes to synthesis, perhaps sooner, real work on C can begin.
At release, or formal release after shuttle run chips, we are likely to have both available.
SPIN needs to be the unified thing it is. Some tweaks are good, but having it be unified with PASM and the P2 itself is a big deal. Anyone who dips their toe in us likely to get the benefits.
Making SPIN like other things runs the risk of diluting those benefits and does not make sense given other tools can and will be made available.
I'm not suggesting that Chip needs to work on the C compiler. That is better left for the GCC gurus that did the PropGCC implementation on the P1. What I am suggesting is that Parallax kick off a PropGCC effort for the P2, with paid consultants like they did for P1. To be honest, I think it is very late in the game to do this on the P2, but there's no time like the present to get started. Given the current state of the P2 development, we probably got another year or two before we see silicon.
May be risk perception too. That gate is why I wrote what I did.
We do have the one instruction needed for C. David requested it. Is there more needed, or are we talking library code, etc... ?
(1) A "base + offset" addressing mode, similar to the PTRA[INDEX] mode but for any registers and with a fairly large possible offset (ideally 20 bits). Maybe ALTI can already do this, but if so I've missed it in the docs. It'd be OK if offset has to be an immediate, and I would expect that we would need an ALTxx prefix of some sort on the instruction to make this work. The PTRx addressing modes are great, but (a) we only have two PTR registers, one of which will probably be reserved for stack, and (b) the available offsets are fairly limited, I think.
(2) A compressed instruction mode. This one probably is too late, but many architectures have a 16 bit subset that can expand out to the full 32 bit instructions (like THUMB for ARM or RV32C for RISC-V). The C compiler is likely to heavily use a relatively small set of 16 or 32 registers, very few instructions other than branches will be conditional, and just a few instructions (like MOV, ADD, JMP, CMP) will occur frequently. So there's lots of room to compress the instruction stream. This would only make sense in HUBEXEC, of course, but it woud allow us to put a lot more code into HUB. Catalina and PropGCC both came up with compressed schemes for P1, and they both performed pretty well.
The core of the streamer looks to be able to handle the main data flows, and some kludged DDR is possible, but more native DDR could make sense ?
It may be the new tight-loop support, can allow a dedicated COG to SW manage XIP, but ideally this should be tested and verified.
I don't know that a special ALTxx instruction would be any more efficient than:
Because addressing deals with 20-bit values, you'll need LOC to supply the base address.
One thing I've never understood about your interest in XIP is that an XIP-friendly memory chip would only work for one cog. I think you must be envisioning one central program running on one cog, with the other cogs doing smaller things.
I guess I didn't explain it well, I was referring to data read/write (e.g. from offsets in a structure) rather than branches. So what I'd like would be a more efficient way of doing:
mov temp, basereg add temp, #imm_offset ' or even better ##imm_offset wrlong data, tempThis is pretty similar to but without requiring one of the PTRx registers (and without necessarily scaling the immediate offset). There are already some data paths there for handling PTRA/PTRB, I'm just wondering how hard it would be to (a) substitute another register as the source, and/or (b) allow the imm_offset to be extended.This kind of pattern is pretty common. In fastspin I had it do
add basereg, #imm_offset ' or even better ##imm_offset wrlong data, basereg sub basereg, #imm_offset ' restore original value of baseregand then later try to merge adjacent add/sub pairs, but obviously that isn't always possible.There is nothing technically stopping more than one COG from reaching into XIP memory, except that would thrash the bus more, and increase latencies. In some cases, that could be tolerable.
Usually the 'main code' would run on a single P2 COG, as it will follow other MCU models.
Users can, and will, pull out 'driver level like' functions to run on other COGS. Some of those may creep into HUB space, but the general nature is they would be loaded and run without being moved.
XIP allows the 'main code' to place most often used functions in HUB, and then call into further memory, where the usual size-speed trade-offs apply. Code like POST, or Setup menus, are some examples of not-used-often, but still required to be available code.
I see.
You could do this:
No cleanup needed, then. (Wait... That's three instructions, not two.)