Shop OBEX P1 Docs P2 Docs Learn Events
HLL support requirements — Parallax Forums

HLL support requirements

David Betz wrote: »
Seairth wrote: »
I think the Spin effort is largely to make sure the P2 instruction set will efficiently support HLLs.
I think it is Chip's plan to build a Spin2 virtual machine and a compiler that generates byte codes for that VM. While that will certainly exercise the instruction set, I'm not sure it is a good test of what is needed to implement high level languages many of which will likely compile to native code. However, Eric's fastspin might be a good test.

Indeed. It's why I also pointed out the need to get C/C++ support going. The Spin focus is mostly because it's what Chip knows best.

But, to allay @BrianFairchild's concerns, maybe there's another way we can approach this without having to actually get languages fully implemented right now. It seems that most of these discussions center around higher-level abstractions that are common in various programming paradigms. We are obviously not worried about simple if/while/for imperative concepts. Instead, we are discussing concepts like function pointers, encapsulation, etc. Even datatyping (e.g. did we have an easy means to deal with 8-bit and 16-bit data, not just 32-bit data?). Given that, is it possible to define a list of the most common higher-level concepts that we think would cover the needs of the most-likely supported programming languages? For example:

* Data types:
- 8-bit, 16-bit, 32-bit, 64-bit(?) numeric values (signed, unsigned, extending, truncating, etc.)
- DateTime (is this just another numeric value, or does it have different semantics?)
- Character (including multi-byte)
- String
- Enumerations
- Sets/Lists/Tuples
* Null-handling
* Function pointers
* Encapsulation
* Iterators
* Map/Reduce/Filter
* Ternary operators (just kidding, Heater!)

IMPORTANT NOTE: I am not suggesting that the P2 must have single-instruction support for all of these things. I'm just suggesting that the P2 should be reasonably capable of supporting these concepts without going through contortions. For many/most of those items listed above, that's already the case. Just ignore those items and focus on the ones that we aren't so sure about.

Comments

  • Focusing on a specific topic, does the P2 provide good support non-ASCII character sets? Can we easily handle UTF-8 characters/strings? The byte-oriented Hub memory certainly allows efficient storage and access, but can it be easily processed/manipulated in the cog registers? Or is this just not going to be a concern for non-English speaking users of the P2?
  • Nothing on your list has anything to do with the Propeller 2 hardware or instruction set, as that can all be supported easily with the current set, for that matter everything on your list meshes well with the Propeller 1.

    Though stack support is the only thing that would make things a lot easier. It is possible to create stacks using even the early Prop 2 design, though it would be easier with HW support (does the current Propeller 2 have HW stack support, I am still catching up).

    And what is wrong with ternary operators? I use them often in C, as often they are a clearer way of doing something or another than using things like if.
  • i
    Seairth wrote: »
    Focusing on a specific topic, does the P2 provide good support non-ASCII character sets? Can we easily handle UTF-8 characters/strings? The byte-oriented Hub memory certainly allows efficient storage and access, but can it be easily processed/manipulated in the cog registers? Or is this just not going to be a concern for non-English speaking users of the P2?

    COG byte instructions were added.


  • Heater.Heater. Posts: 21,230
    Seairth,

    I'm not sure where you are going with this.

    We have had five decades or so of research into compiler design and CPU instruction set design. All kind of things have been tried.

    For example: In the 1980's Intel came up with what was supposed to be a super fast replacement for the clunky old x86, the Intel i860. That thing made heavy use of pipelines and could execute integer and floating point instructions in parallel. Problem was it turned out to be really hard to program in assembler and then even harder for compiler writers to generate code for it. Fail!.

    Then there was the Intel Itanium. Again supposed to be a super fast x86 replacement. Again it's Very Long Instruction Word (VLIW) architecture could do many things in parallel. Again in turned out that compiler technology could not make efficient use of it. Fail!

    Meanwhile, it turns out that one can write a C/C++ compiler for x86 that uses nothing but MOV instructions.

    Also meanwhile, there was the Reduced Instruction Set Computer (RISC) movement. That removed all redundant instructions from the machine and favored ones compiler writers could actually use. See ARM.

    The current pinnacle of this synergy between instruction set design and compiler capability is embodies in the RISC V architecture: https://riscv.org/ designed by some of the guys that invented the RISC idea but with experience since then added to the mix.

    And, also meanwhile, the Propeller was no designed to be compiler friendly. It was designed to be assembler programmer friendly. And so it is. PASM is perhaps the simplest assembly language programming environments I have ever used. Wonderful.

    I have to admit. The P2 has me confused. As pointed out it has hundreds of instructions a compiler will never use, except by means of special keywords, built-ins or intrinsics. Italso looks far too big and complicated to make assembly language programmers happy. Or perhaps I'm just getting too old to hold all those details in my head.

    Anyway, it's far too late to be thinking about changing the P2 architecture to make it more compiler friendly.

    Unicode has nothing to do with this. That is just data.










  • Heater.Heater. Posts: 21,230
    davidsaunders,
    And what is wrong with ternary operators? I use them often in C, as often they are a clearer way of doing something or another than using things like if.
    Plenty:

    1) They are redundant. We already have syntax for making selections. "if ... else ...". Why do we need another. KISS and all that.

    2) They are an extra complication for a beginner. Another syntactic/semantic twist to learn. A couple more weird operator symbols to deal with.

    3) I don't believe they make anything clearer.
  • yetiyeti Posts: 818
    edited 2017-03-01 16:51
    @heater ... an "Inline if" is nice to have. It does not have to be the way C writes it. Accepting to type some more chars may invrease readybility:
    (yeti@kumari:18)~$ python
    Python 2.7.9 (default, Jun 29 2016, 13:08:31) 
    [GCC 4.9.2] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> print "yep" if 1<2 else "nope"
    yep
    >>> print "yep" if 1>2 else "nope"
    nope
    >>> _
    
  • Nothing on your list has anything to do with the Propeller 2 hardware or instruction set, as that can all be supported easily with the current set, for that matter everything on your list meshes well with the Propeller 1.

    That's not entirely true. As I keep pointing out, Chip just added new instructions to better deal with sub-32-bit data, specifically to make like easier for HLLs. And that list is certainly not complete.

    But, I will agree that all of it can be technically done right now. And it might be that it can all be easily done right now. Or maybe no one cares, at this point, if it's even easy to do. I just figured this might be a different approach to getting the P2 shipped without first waiting for a new version of Spin (or any other language, for that matter) to prove it all out.
    Though stack support is the only thing that would make things a lot easier. It is possible to create stacks using even the early Prop 2 design, though it would be easier with HW support (does the current Propeller 2 have HW stack support, I am still catching up).

    My understanding is that the following stack support exists:

    * internal, 22-bit, 8-deep branch/return stack
    * PTRA/PTRB instructions to treat hub memory like a stack

    In some cases, I would much rather use LUT memory as a stack, as the performance penalty for using the hub as a stack could be quite high. But, to do that, you will need to manually do it yourself.

    And what is wrong with ternary operators? I use them often in C, as often they are a clearer way of doing something or another than using things like if.

    That was a bit of a joke, actually. There's been a lengthy discussion on the "New Spin" thread about whether they should be added to the language. No need to rehash it here, especially since ternary operators don't really have anything to do with architecture support.

  • yeti wrote: »
    @heater ... an "Inline if" is nice to have. It does not have to be the way C writes it. Accepting to type some more chars may invrease readybility:
    (yeti@kumari:18)~$ python
    Python 2.7.9 (default, Jun 29 2016, 13:08:31) 
    [GCC 4.9.2] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> print "yep" if 1<2 else "nope"
    yep
    >>> print "yep" if 1>2 else "nope"
    nope
    >>> _
    
    That's actually not quite the same thing. How would you do this in Python? This uses the result of the ternary operator in an expression. How does Python handle that?
    x = a < 2 ? 3 : 4;
    

  • I'm sitting here updating a real-world commercial embedded application as I type this. It runs on an 8-bit chip and is controlling stepper motors, talking to LCD display, looking at sensors, making PWM signals. All good embedded stuff. It's written in C. On of the reports out of my compiler is instruction usage. Here are the top 20 most used instructions...

    ldi 22.6% 22.6%
    call 8.4% 31.0%
    cpi 6.7% 37.7%
    rjmp 6.4% 44.1%
    st 5.8% 50.0%
    lds 4.6% 54.5%
    brne 4.3% 58.8%
    sts 4.1% 62.8%
    ldd 3.8% 66.6%
    mov 2.9% 69.5%
    std 2.4% 71.9%
    adiw 2.4% 74.3%
    breq 2.2% 76.6%
    subi 2.2% 78.8%
    ld 1.5% 80.3%
    rcall 1.2% 81.5%
    movw 1.2% 82.7%
    clr 1.1% 83.8%
    ret 1.1% 84.9%
    sbci 1.1% 86.0%

    Column 1 is the instruction, 2 is the % of the total count that instruction accounts for, 3 is the cumulative total. So 20 unique instructions account for 86% of the usage. (Just 5 instruction account for 50%.) Out of 112 different instructions there are 39 that are not used at all.


    That's the sort of analysis that should be done.
  • yetiyeti Posts: 818
    edited 2017-03-01 17:14
    David Betz wrote: »
    How does Python handle that?
    x = a < 2 ? 3 : 4;
    
    >>> a = 11
    >>> x = 3 if a < 2 else 4
    >>> print x
    4
    
  • Heater.Heater. Posts: 21,230
    An inline "if" in a language like Python is absurd.

    Python is basically line based and uses white space block delimiting.

    I always wondered why a normal "if" in Python requires a ":" like so:
    if x > 50:
        doSometing(...)
    
    Given that the idea of Python is to minimize spurious syntactic marks like "(", ")", "{", "}" etc by using white space then that stupid ":" is redundant and sticks out like a sore thumb.

    Stupid Python.
  • @Heater ... Python has lost it's purity loooong ago:
    >>> print [num * 2 for num in 1,2,3]
    [2, 4, 6]
    
  • potatohead wrote: »
    Seairth wrote: »
    Focusing on a specific topic, does the P2 provide good support non-ASCII character sets? Can we easily handle UTF-8 characters/strings? The byte-oriented Hub memory certainly allows efficient storage and access, but can it be easily processed/manipulated in the cog registers? Or is this just not going to be a concern for non-English speaking users of the P2?

    COG byte instructions were added.


    True. And that may be enough. Thinking through it a bit....

    It looks like most uses of UTF-8 limit it to no more than 4 bytes, which will conveniently fit into a single register. So, for instance, how much work would it take to read a single character from hub into a cog register? Or to write a character back to the hub?
  • (doh! that's what I get for making the joke about the ternary operator converation!)
  • Heater. wrote: »
    I'm not sure where you are going with this.

    What I was getting at was trying to address a concern that Brian expressed in the "New Spin" thread.

    1. I thought the "New Spin" thread was partial meant to get a HLL working to get some test coverage of the P2 from that perspective.
    2. Brian was concerned (I think) that this would just unnecessarily delay the P2 release further.
    3. I was trying to come up with another approach that somewhat allowed the purpose I identified in (1) while reducing the likelihood of the concern expressed in (2).

    If this is not a good way to do it, so be it! Just let the thread die.
  • Heater.Heater. Posts: 21,230
    Brian,
    That's the sort of analysis that should be done.
    I think we all know what you mean.

    That sort of analysis as been going on for decades. I recall reading about such analysis when Motorola was designing the 8 bit 6809. That sort of analysis led to RISC processor idea of 1980.

    It's far too late to carry out that kind of analysis and have the results cause a redesign of the P2.

    It's redundant anyway. Just use the results from history and implement the RISC V instruction set !

    BUT, as I said, the Propeller is not designed to be compiler friendly. There is a whole other motivation going on here.

  • potatoheadpotatohead Posts: 10,253
    edited 2017-03-01 17:45
    I'm not sure there is cause to worry yet. Chip is coming back up to speed on SPIN, shaking off the Verilog.

    The language feature discussion is all over the place. Chip will boil all that down to the few necessary bits, and those will get considered in the context of PASM.

    This is what we want for sure.

    When the languages get prototypes and bootstrapping, then we get the more complete instructions and hardware exercise we also want.

    Frankly, bootstrapping openspin onto P2 with a core set of instructions is enough to get the instruction and hardware testing moving nicely and concurrently with the spin project. A bunch of that code is very likely to be reused, near directly, in the final Spin 2.

    Open spin has simple in line PASM needed to exercise the hardware works as intended. IMHO, that is a big enabler for testing. People can work in a nice framework, doing little things without the pain of authoring it all in PASM. (Though that isn't bad, surprisingly)

    My .02 YMMV.

    In any case, once Chip has his head back into spin, that should move at a nice clip to at least prototype and get a body of code started to vet the rest of the intended features, whatever they are.
  • jmgjmg Posts: 15,140
    Seairth wrote: »
    * Data types:
    - 8-bit, 16-bit, 32-bit, 64-bit(?) numeric values (signed, unsigned, extending, truncating, etc.)
    - DateTime (is this just another numeric value, or does it have different semantics?)
    - Character (including multi-byte)
    - String
    - Enumerations
    - Sets/Lists/Tuples

    No mention of 1-bit, 4-bit, or floating point, or > 64b ?
    ( What happened to BCD support ?)


  • Heater. wrote: »
    An inline "if" in a language like Python is absurd.

    Python is basically line based and uses white space block delimiting.

    I always wondered why a normal "if" in Python requires a ":" like so:
    if x > 50:
        doSometing(...)
    
    Given that the idea of Python is to minimize spurious syntactic marks like "(", ")", "{", "}" etc by using white space then that stupid ":" is redundant and sticks out like a sore thumb.

    Stupid Python.

    Yeah, looks like Business And Scientific Instruction Code.....gone wrong ;-)
  • Heater.Heater. Posts: 21,230
    Mickster,

    "Business And Scientific Instruction Code", What is that?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2017-03-02 12:05
    BASIC by any other name is still BASIC
  • I can see how having instructions to directly deal with byte and word sized data could make life easier for a compiler writer. Though the other data types you listed are rarely supported in HW, as they are easy enough to implement in software.

    As to null handling, that is just a jump if zero, or jump if non zero case.

    I will post my comment about ternary operators in the Spin2 thread.
  • Heater. wrote: »
    Mickster,

    "Business And Scientific Instruction Code", What is that?

    ha, he got you there...

    Mike
  • Nice one!
  • "Business And Scientific Instruction Code"?

    Someone making up meanings?

    I have heard it called "Beneficial All purpose Instruction Code", "Business All purpose Symbolic Instruction Code", Been Any Symbol Instruction Code", "Beginners All purpose Symbolic Instruction Code", "Beginners And Systems Instruction Code", and a few other names in widely published documents about the language, though that is a new one.
  • Heater.Heater. Posts: 21,230
    msrobots,
    ha, he got you there...
    Eh? We all know what BASIC is. My "What is that?" is asking if that was a joke or an error or a commonly used, but incorrect, reverse acronym that had never heard of before.

    I'm still not sure which was meant.
Sign In or Register to comment.