Spin3 -- verilog compatible?
rjo__
Posts: 2,114
in Propeller 2
With the Prop2 about to hit emulator street, I thought it would be nice to take a break and think about how Chip should deal with his forth-coming mid-life crises;O
So we are talking about a post-Spin2 cycle here. What would it take to make Spin3/PASM3 compatible with a sub(super)-set of Verilog? Hardware wise that is?
So we are talking about a post-Spin2 cycle here. What would it take to make Spin3/PASM3 compatible with a sub(super)-set of Verilog? Hardware wise that is?
Comments
Did I miss something? I have never heard of Spin 2. As far as I know there is only Spin. And you are alrady looking at Spin 3!
I'm not sure what needs to be compatible with verilog here. The Spin interpreter is not part of the PII ROM. If you want to run a Spin program you need to download an interpreter to the chip, in the binary with everything else I guess, and it will be started in a COG and pointed at your Spin byte codes.
Someone correct me if I am wrong here.
So Spin for the PII need not know anything about verilog. It needs to have an interpreter written in the PII PASM.
In looking at the outer appearance of Verilog modules and Propeller objects, they are very similar, but of course not entirely so.
One Verilog construct that I particularly like is the ability to concatenate variable parts of various registers.
In Spin that could look like
x[7..0]:=*{io[y],io[a],io[d],io,...etc}*
................ What would it take to make Spin3/PASM3 compatible with a sub(super)-set of Verilog? Hardware wise that is?
??????????
Verilog is a hardware definition language, spin is a computer programming language. In what way would or could they be compatible?
I think you are right... only because you are almost always right:)
Chuckle, many people never get to understand that
Some Verilog syntax might be nice in a language like Spin where people tend to do a lot of bit twiddling. No reason something like:
x[7..0]:=*{io[y],io[a],io[d],io,...etc}*
could not be in the language. I wonder if it makes much sense though considering the semantics are so different. Verilog wires up the gates so that the statement all happens at one time, where as a language like Spin would have to generate a big lot of sequentially executing code to do that. Mind you languages like Lua can similar things:
a, b, c = x, y, z
I'm expecting that Chip will be adding a few new features to Spin to make using new PII features easy. Hopefully the new Spin will be backwards compatible with the current Spin.
And there I do worry about compatibility. Ideally all that code available in OBEX and elsewhere would be usable on the PII out of the box.
That's probably true for all the Spin but I'm guessing none of the PASM parts will work with out, well, work being done on them. Who is going to do all that?
Ah, so you want verilog support for Spin bytecodes - see the other threads on Faster Spin on P1V and also the thread on FPGA Forth Machines.Usually you still do have CPU opcodes in there somewhere, for the more complex Bytecode calls.The simpler ones, and the bytecode feeder engine can be coded in verilog, but the gains are not great.
P1 spin is in ROM so is rather a locked-beast, but P2 spin will be RAM loaded, and so much more evolving in nature.
Now with OpenSpin it's possible for anybody to add enhancements. So I would suggest that anyone that is would like to see enhancements to Spin just go ahead and implement them.
I think you are right... only because you are almost always right:)
...Ideally all that code available in OBEX and elsewhere would be usable on the PII out of the box.
That's probably true for all the Spin but I'm guessing none of the PASM parts will work with out, well, work being done on them. Who is going to do all that?
So besides CP/M and ZiCog we need a P1 emulator for the P2!
Should run faster and has more pins...
Mike
'never happened?' - I saw Spin variants published, but because the original Spin is in ROM, it is locked-in as a de-facto standard, and loading a new-spin was never worth the small gains to most users.
I think tie tooling cost of doing a ROM revision meant a ROM change never happened, which may have been what you meant ?
P2 will have a Soft-Spin, and that certainly will have revisions over time.
That means Spin-version control will be a new discipline for many P2 users
People were free to augment SPIN and we saw some little things done.
Just needs to compile to byte code P1 understands.
That will make it as easy for Spin users to share objects as it is for the users of all the different Forths to share their Forth word definitions
I worry that Spin has no formal specification of it's syntax or semantics. Yes we have the Propeller manual but really. Also there is no formal definition of the Spin byte codes. That leads to, for example, Roy having to rely on reverse engineering Chip's assembler version of the Spin compiler to create OpenSpin rather than building a nice clean compiler from the language spec. Roy did a great job on that I think, by the way.
I'm guessing that Chip will tweak the Spin compiler for the PII, from the existing Spin assembler sources. Being turbo, I get the feeling Chip can do that in x86 assembler faster than learning C++.
Poor old Roy, or somebody, will have to reverse engineer that x86 asm again in order to update OpenSpin for for Spin II.
Ick.
On one hand, I love SPIN as Chip wrote it, and I'm pretty sure the same sorts of ideas will end up in SPIN 2. And I want that, loose behavior and all.
But, reverse engineering that is a PITA, though it's going to be easier the second time. Chip is building off the P1 code base, so changes will be a sort of delta for Roy. Maybe not so bad this time around.
SPIN having some limits hurt it a little over the years, but not changing much at all really helped! We've a great, stable, robust, useful code body to work with. I really want that to happen again, and the only way to make it happen is to leave SPIN alone once it's good enough to release.
In this way, Chip is the definition. Once it has been reverse engineered, that can be the definition.
Building things more open, standards body style, has it's merits, but the beauty of SPIN+PASM is how it's all linked to the Propeller, and I really want that to happen as well.
It's easy enough to build away from that once it's done. We have gcc and friends to carry that torch, and with the more roomy P2, I'll bet that all rocks pretty hard.
Another way to improve Spin is to add features to the language to make it more powerful. People have proposed adding native floating point support, types, and other features. None of this was added to the Prop Tool, and only a few new features have been added to OpenSpin.
As I suggested, people can add their own favorite features to a copy of OpenSpin. If the feature catches on maybe Parallax will add it to the official version of OpenSpin.
You kind of have to have your head around the entire process... that's a pretty big head... and lotsoexperiences.
But I do absolutely love, slick as ham on an open fire, couldn't be more fun, can't believe everyone isn't doing it ... adding Smile to the P1V... And I find it relatively simple to understand enough about what others have done to be able to use the extra pins and ports and widgets that go along with it etc. etc.
So... I was thinking that it couldn't be that hard to add a little hpga(hobby programmable gate array) and get Spin to support it in a very limited way. On the other hand... in order to get things the way he wants them and keep the P2 cool, Chip has pushed logic out to the temperate zones... So, I don't know how many gates he could add even if he wanted to program them.