Bytecodes, WebAssembly binary format & human-readable "Linear Assembly Bytecode"
jmg
Posts: 15,173
From the other now closed thread, WebAssembly is relatively new, but has some highly portable merit, and if new byte codes are going to be invented for P2, why not use an existing body of work ?
Checking back into fasmg forum, reveals this mention of WebAssembly
and this wiki says
" WebAssembly is a portable stack machine which is designed to be faster to parse than JavaScript, as well as faster to execute."
and this seems a good idea :
It defines a WebAssembly binary format, which is not designed to be used by humans, as well as a human-readable "Linear Assembly Bytecode" format that resembles traditional assembly languages.
Seems quite new, but also well resourced. ("The team working on WebAssembly includes people from Mozilla, Microsoft, Google and Apple.")
Can P2 byte-code work, leverage those WebAssembly byte-codes, and so tap-into a ship-load of resource ?
Seems the text "linear assembly bytecode" (Intermediate Representation) is a very good idea, and Spin could generate that, and then compile that to P2 byte codes.
That common pivot point, also means any language that generated "linear assembly bytecode" source, could be used.
The work done in the fasmg forum, has this link
https://board.flatassembler.net/download.php?id=7564
which shows some of the framework needed to do the IR -> .wasm(binary) step.
Checking back into fasmg forum, reveals this mention of WebAssembly
and this wiki says
" WebAssembly is a portable stack machine which is designed to be faster to parse than JavaScript, as well as faster to execute."
and this seems a good idea :
It defines a WebAssembly binary format, which is not designed to be used by humans, as well as a human-readable "Linear Assembly Bytecode" format that resembles traditional assembly languages.
Seems quite new, but also well resourced. ("The team working on WebAssembly includes people from Mozilla, Microsoft, Google and Apple.")
Can P2 byte-code work, leverage those WebAssembly byte-codes, and so tap-into a ship-load of resource ?
Seems the text "linear assembly bytecode" (Intermediate Representation) is a very good idea, and Spin could generate that, and then compile that to P2 byte codes.
That common pivot point, also means any language that generated "linear assembly bytecode" source, could be used.
The work done in the fasmg forum, has this link
https://board.flatassembler.net/download.php?id=7564
which shows some of the framework needed to do the IR -> .wasm(binary) step.
Comments
If I understand correctly the idea is to be able to compile C or C++ or whatever language to some kind of compact byte code that is then run by the browser.
Basically the good old Java applets but integrated into the browser.
Well, guess what? We can already "transpile" C and C++ to Javascript, with Emscripten, and it runs pretty damn fast. So much so that compiling Spin programs in the browser is about half as fast as the original OpenSpin compiler running natively.
WebAssembly adds nothing. Except a whole pile of new security vulnerabilities into our browsers.
Now, if you are suggesting that WebAssebmly byte codes are suitable for use in a micro-controller that is a different case. I suspect not.
Better brains than mine, seem to think it is worth the effort, so must add something.
Given P2 is about to get a new set of byte codes, it seems only sensible to look around at what is out there, that could be used.
More importantly, if you can use other work, much of the education and documentation can be shared.
Even better if many languages can feed into P2.
It would make P2 that much easier to sell.
The approach they use seems quite flexible to me, of "linear assembly bytecode" (Intermediate Representation) , as well as the S-Expressions middle formats, and the fasmg examples seem to show the IR-> .MASM(bin) is within fasmg's ability.
I've also tested fasmg enough to show fasmg can manage PASM -> binary 'conventional assembling'
Even a compatible subset, using their semantics in IR, would I think be worthwhile.
Better brains than mine have been wrong before
The last thing the "web" needs is another compile to byte code system. Been there, done that with Java applets.
What do think happens next? They devise a complex scheme to "Just In Time" compile those byte codes to native code. Hmm...that is what happens with Javascript already. I see no significant gains there.
The P2 is not about to get a new set of byte codes. The P1 had a byte code interpreter built in. As far as I can tell the P2 does not.
When we have the chip out the door anyone is welcome to make whatever language and run time system they like for it.
I just hope and pray the P2 gets out the frikken door...
Why are we looking at the grand end design, why not just a build on the original idea. It is an awful lot of responsibility to predict a products future usefulness. Time with all hands on will do that.
See the other threads
byte codes come up frequently in that thread.
However, the reality is that the P1 chip has a Spin byte code interpreter built in to it's ROM. That is the first code that runs when it boot's up. You have to deal with some Spin byte codes on the P1 no matter what language or run time you want to use.
The P2 does not. Everything is open.
</rant>
dp
@Peter J. has build a quite fast system running on P1 and (earlier?) P2.
As for Byte Codes used from different languages, MSIL comes to my mind MS and other provide a lot of languages able to compile code for the NetFramework, and most of the basic stuff is open Source, there even is a NetCompactFramework especially made for embedded use.
But since the Spin Interpreter will not be in a ROM as on the P1, all of this is moot.
There will be tons of different Spin-Interpreter out - you have to load them anyways together with you program.
Since I hope that Parallax will open source stuff like that nothing will prevent anyone to tweak the spin interpreter to fit his own software.
So it will happen.
But it is not a bad thing, in the opposite.
What I also think to be very important is to define some interoperability with C code and SPIN code.
So SPIN should be able to call C functions and C should be able to call SPIN methods when running on the same chip in different COGs.
Something like EXTERNAL function(...) returning ... would be nice on both sides of the language-pond
Enjoy!
Mike
Jmg, you asked about SPIN development. It's in x86 assembly. Spin 2 will most likely adopt what made sense from SPIN 1. Pnut should expand to handle SPIN + PASM, one unified syntax, one file, if a person wants to do that. The first time around, pnut got it all done, feature complete, but lean. Honestly, the best comparison actually is Javascript, how it was developed, cloned, expanded upon.
Chip seems to have something a lot of people don't, and that's an ability to relate the concepts back to the gates, holistically, language, etc... being given consideration. It's one of the reasons why I've urged "Chip, be Chip" in this respect. The product of that will have high value to a fair number of people. Buyers early on, advocates.
And I know that's off the beaten path, but it's super important to:
Parallax Education, who will build on what they've got now. Non trivial concern. I and numerous others, have brought people up on this stuff, and that combination is slick. Let's say, "low friction." I personally value it for that reason. Honestly, I can forget half of what I know about SPIN and PASM and pick up just fine. Comes back easy. Worth it.
P1 users, who will expect to work in similar ways.
Others, who want to maximize the hardware in the chip. That's going to mean PASM, particularly early on. Maybe over time a bunch of stuff gets abstracted, but I'll bet it takes a good long while.
The C effort in parallel with this is equally important for reasons we've all hashed out here many times. Frankly, I believe that should be done in the way most effective to that environment, and if that means GAS syntax to get rocking, fine! We can author tools to translate / filter later on. Or, if it's not too much trouble, it would be spiffy to have PASM syntax intact in GAS, like we have in P1.
It's also my opinion this chip will be much better suited to C than P1 is. Not that it's bad. From what I see out there, amazing stuff got done on P1.
I knew earlier stuff was in x86 asm, but hoped that was left behind for something more productive and developer portable. I had expected Ken to ensure that ?
Yup, that is why I looked into fasmg.
fasmg is small and nimble and very powerful, I'd expect it to appeal to Prop users for exactly those reasons.
pnut-syntax-ASM was far too limited for my taste, and GAS rather too cumbersome, and did not yet support P2.
So, I looked at what was needed to get P2 on fasmg.
Turns out, not a great deal - just some smart tips from the fasmg author, as fasmg is not your father's assembler.
See the fasmg thread.
Mostly, I focused on the Prop X mnemonic prefix & suffix handling, as that is more Prop-X-unique.
The binary opcode encoding is just a matter of macro legwork, from there, for specific P1 or P2 code generates.
It's nuts to be writing a compiler in assembly language. Or any significant application for that matter. It's nuts to have a compiler implementation in assembler be the definition of the language it compiles! Such that people have to reverse engineer and analyse the behavior of that assembler program in order to create a cross platform alternative. See OpenSpin.
I know Chip has that kind of turbo mind that can code in assembler fluently and is no doubt very comfortable with it. Heck, back in the day I found driving the Win32 API for Windows 3.1 in assembler was easier for me than using C++ !
But consider this. The P1 was designed gate by gate. If I understand correctly. Only after starting on the P2 did Chip realize that perhaps it's better to use Verilog.