Shop Learn
Fast Bytecode Interpreter - Page 17 — Parallax Forums

Fast Bytecode Interpreter

1141517192030

Comments

  • jmg wrote: »
    David Betz wrote: »
    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!
  • jmgjmg Posts: 14,663
    edited 2017-04-04 03:56
    Roy Eltham wrote: »
    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.

  • cgraceycgracey Posts: 13,574
    Roy Eltham wrote: »
    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.
  • jmgjmg Posts: 14,663
    edited 2017-04-04 04:22
    Roy Eltham wrote: »
    ...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. ;)
  • jmgjmg Posts: 14,663
    JasonDorie wrote: »
    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

  • JRetSapDoogJRetSapDoog Posts: 875
    edited 2017-04-04 10:18
    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....
    jmg wrote: »
    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.
  • jmgjmg Posts: 14,663
    Roy Eltham wrote: »
    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.

  • jmg,
    I guess you didn't read the rest of the line, then?
  • jmgjmg Posts: 14,663
    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.
    Yup
    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.
    What are the specific changes you want there ?
    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).
    Agreed.

  • Roy Eltham wrote: »
    If you get to know me, you'll find that I generally don't hold back or bottle things up ever.

    For the record, I'm in complete agreement with you on this, I just thought your expression of it was funny. :)
  • JasonDorie,
    I figured as much. I know you agree, because it makes sense, right? We have very similar backgrounds on coding I assume.
  • JRetSapDoogJRetSapDoog Posts: 875
    edited 2017-04-04 08:20
    @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.
  • jmgjmg Posts: 14,663
    @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.

    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 ?
    As for loop sweeping directions, perhaps I'm behind the times there.
    I was meaning for other languages in general, not Spin.

  • JRetSapDoogJRetSapDoog Posts: 875
    edited 2017-04-04 10:28
    @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.

    Now about those multi-dimensional arrays....
  • Two things:

    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.

  • potatohead wrote: »
    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.

  • I agree with you. The order likely reflects business realities.

    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... ?
  • Dave HeinDave Hein Posts: 6,290
    edited 2017-04-04 22:21
    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.
  • Agreed with that too.
  • 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.
  • jmgjmg Posts: 14,663
    ersmith wrote: »
    (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.
  • cgraceycgracey Posts: 13,574
    edited 2017-04-06 22:36
    ersmith wrote: »
    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.
  • cgraceycgracey Posts: 13,574
    edited 2017-04-06 22:36
    jmg wrote: »
    ersmith wrote: »
    (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.
  • ersmithersmith Posts: 4,890
    edited 2017-04-06 22:50
    cgracey wrote: »
    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.
  • jmgjmg Posts: 14,663
    cgracey wrote: »
    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.



  • cgraceycgracey Posts: 13,574
    edited 2017-04-06 23:23
    ersmith wrote: »
    cgracey wrote: »
    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.)
Sign In or Register to comment.