HLL support requirements
Seairth
Posts: 2,474
in Propeller 2
David Betz wrote: »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.I think the Spin effort is largely to make sure the P2 instruction set will efficiently support HLLs.
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
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.
COG byte instructions were added.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
No mention of 1-bit, 4-bit, or floating point, or > 64b ?
( What happened to BCD support ?)
Yeah, looks like Business And Scientific Instruction Code.....gone wrong ;-)
"Business And Scientific Instruction Code", What is that?
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.
ha, he got you there...
Mike
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.
I'm still not sure which was meant.