I could have sworn I've read emails from someone that did a MIPS cog port, but it hasn't made it to the 'official' opensmalltalk-vm repository as yet.
A complication for a RiscV cog that I would anticipate from my fairly limited reading on RiscV is that the actual instruction set for any particular cpu can vary quite a lot because of the building-block nature of the specification. I hope it's not quite as confusing as it seems to me so far.
On 2022-06-15, at 5:59 AM, ken.dickey@whidbey.com wrote:
On 2022-06-15 03:06, Gerald Klix via Cuis-dev wrote:
Nevertheless I don't understand Ken's answer.
To make a story too long short: Obviously there never was a JIT version of the opensmalltalk VM for the RiscV-architecture (I don't know to state this in a more explicit way).
Gerald,
Sorry to be confusing.
OpenSmalltalk-VM has many delivery targets. OSs: Windows, Linux, MacOS, SunOS. [?RiscOS?]
Ah. RISC OS. Yes, well, I haven't had any time to update that in quite a while. I really would like to do a cog version since we have the ARM cog already sorted, but *time*. What even is that thing *spare time*?
CPU Architectures: Intel, Arm, now Risc-V 32 bit, 64 bit variants Displays & plugins [X-Windows, FrameBuffer, ..]
There are three basic VM "flavors" Original stack VM ["Back to the Future"] Spur [Stack VM with top of stack mapped to machine registers] a.k.s. squeak.stack.spur Cog [Above + JIT] a.k.a. squeak.cog.spur
The VM easiest to port is squeak.stack.spur
The squeak.stack.spur flavor is running now on RISC-V RV64 (64 bit) Debian Linux.
No JIT (no squeak,cog.spur) yet.
HTH, -KenD
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SDP: Search and Destroy Pointer
On 2022-06-15 10:22, tim Rowledge wrote:
A complication for a RiscV cog that I would anticipate from my fairly limited reading on RiscV is that the actual instruction set for any particular cpu can vary quite a lot because of the building-block nature of the specification. I hope it's not quite as confusing as it seems to me so far.
I expect RV64G to be pretty common. Good as a baseline.
We can do without the vector stuff or 32 bit for quite a while, particularly until we get more real hardware. ;^)
Good on ya, -KenD
While it is true that RISC-V has a plethora of choices a sensible target for COG would probably be called RV64GC, which is the base 64 bit plus useful things like the FPU and so on. The critical letter is that G which includes F and D the single and double precision float instructions.
On 2022-06-15T19:22:06.000+02:00, tim Rowledge tim@rowledge.org wrote:
I could have sworn I've read emails from someone that did a MIPS cog port, but it hasn't made it to the 'official' opensmalltalk-vm repository as yet. A complication for a RiscV cog that I would anticipate from my fairly limited reading on RiscV is that the actual instruction set for any particular cpu can vary quite a lot because of the building-block nature of the specification. I hope it's not quite as confusing as it seems to me so far.
On 2022-06-15, at 5:59 AM, ken.dickey@whidbey.com wrote: On 2022-06-15 03:06, Gerald Klix via Cuis-dev wrote:
Nevertheless I don't understand Ken's answer.
To make a story too long short: Obviously there never was a JIT version of the opensmalltalk VM for the RiscV-architecture (I don't know to state this in a more explicit way).
Gerald, Sorry to be confusing. OpenSmalltalk-VM has many delivery targets. OSs: Windows, Linux, MacOS, SunOS. [?RiscOS?]
Ah. RISC OS. Yes, well, I haven't had any time to update that in quite a while. I really would like to do a cog version since we have the ARM cog already sorted, but *time*. What even is that thing *spare time*?
CPU Architectures: Intel, Arm, now Risc-V 32 bit, 64 bit variants Displays & plugins [X-Windows, FrameBuffer, ..] There are three basic VM "flavors" Original stack VM ["Back to the Future"] Spur [Stack VM with top of stack mapped to machine registers] a.k.s. squeak.stack.spur Cog [Above + JIT] a.k.a. squeak.cog.spur The VM easiest to port is squeak.stack.spur The squeak.stack.spur flavor is running now on RISC-V RV64 (64 bit) Debian Linux. No JIT (no squeak,cog.spur) yet. HTH, -KenD
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SDP: Search and Destroy Pointer
On 2022-06-15, at 10:46 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
While it is true that RISC-V has a plethora of choices a sensible target for COG would probably be called RV64GC, which is the base 64 bit plus useful things like the FPU and so on. The critical letter is that G which includes F and D the single and double precision float instructions.
That's encouraging; flexibility is wonderful until it becomes impossibly confusing
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- IQ = dx / (1 + dx), where x = age.
On Wed, Jun 15, 2022 at 10:22 AM tim Rowledge tim@rowledge.org wrote:
I could have sworn I've read emails from someone that did a MIPS cog port, but it hasn't made it to the 'official' opensmalltalk-vm repository as yet.
Ryan Macnak did a 32-bit MIPS simulator; it's still in VMMaker.oscog, but it needs a little love to make it simulate fully. AFAIA it was never used to produce C sources and a "real" JIT.
A complication for a RiscV cog that I would anticipate from my fairly limited reading on RiscV is that the actual instruction set for any particular cpu can vary quite a lot because of the building-block nature of the specification. I hope it's not quite as confusing as it seems to me so far.
That's not such an issue for the core Smalltalk JIT. Its use of instruction sets is pretty unsophisticated; for example, it doesn't use vector instructions, etc. The situation is similar on ARMv8. The only sophistication is in locking for the multithreaded FFI (where I implemented both 8.1 and 8.0 style locking; see CogARMv8Compiler protocol multi-threading), initialization & cache flushing code. But one doesn't have to go near these areas if one doesn't want to. So to a first approximation the JIT uses only core ISA instructions.
Now see below in response to Ken's status report "No JIT (no squeak,cog.spur) yet".
On 2022-06-15, at 5:59 AM, ken.dickey@whidbey.com wrote:
On 2022-06-15 03:06, Gerald Klix via Cuis-dev wrote:
Nevertheless I don't understand Ken's answer.
To make a story too long short: Obviously there never was a JIT version
of the
opensmalltalk VM for the RiscV-architecture (I don't know to state this
in a more explicit way).
Gerald,
Sorry to be confusing.
OpenSmalltalk-VM has many delivery targets. OSs: Windows, Linux, MacOS, SunOS. [?RiscOS?]
Ah. RISC OS. Yes, well, I haven't had any time to update that in quite a while. I really would like to do a cog version since we have the ARM cog already sorted, but *time*. What even is that thing *spare time*?
CPU Architectures: Intel, Arm, now Risc-V 32 bit, 64 bit variants Displays & plugins [X-Windows, FrameBuffer, ..]
There are three basic VM "flavors" Original stack VM ["Back to the Future"] Spur [Stack VM with top of stack mapped to machine registers] a.k.s. squeak.stack.spur Cog [Above + JIT] a.k.a. squeak.cog.spur
The VM easiest to port is squeak.stack.spur
The squeak.stack.spur flavor is running now on RISC-V RV64 (64 bit)
Debian Linux.
No JIT (no squeak,cog.spur) yet.
Boris Shingarov has done one but hasn't contributed it back because he's interested in auto-generating the JIT backend (the mapping of the JIT's abstract instruction set to the processor's concrete instructions) from a formal processor description. And, at least when last we talked, he was interested in interpreting the description when generating the code rather than generating the mapping methods (such as concretizeCall, concretizeMoveRR, etc) from the specification. Perhaps Boris would be willing to help someone port his work back so we could have a RISC-V port done quickly.
Tom Braun & Leon Matthes are doing a RISC-V backend now to learn how the JIT works before they work on the incremental garbage collector and compactor with me as a mentor/collaborator. I don't know if they're interested in finishing and/or collaborating with someone to finish, to produce a production RISC-V JIT.
In any case, taking Tom & Leon & Boris's work together should get someone a long way towards a production RISC-V back end. And in generating ARMv8 (fully 64-bit) back ends for Linux aarch64 and MacOS M1/arm64 platforms a number of 64-bit RISC issues have been solved.
Boris, Tom & Leon would you care to comment?
HTH, -KenD
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SDP: Search and Destroy Pointer
_,,,^..^,,,_ best, Eliot
I would like to point out that the J Extension for RISC-V is still being defined. It is meant for Java, Javascript and other managed languages, so the OpenSmalltalk VM would certainly qualify.
Since it is not finished, no current RISC-V implements it yet. And it might not be a popular option even when available. That means that a virtual machine can't count on it and if it runs on non RISC-V processors will have to consider it an option in any case.
So far two items have been worked on: pointer masking and instruction cache coherence.
Pointer masking adds two control registers (optionally per priviledge level) such that any address has its bits indicated by the first register replaced by the corresponding bits in the second register. Something like
effectiveAddress := (mask not and: address) or: (mask and: base)
This allows the same functionality as extensions for other processors, such as TBI (top byte ignore) for ARM, UAI (upper address ignore) for AMD x86-64 and LAM (linear address masking) for Intel x86-64. It also gives hardware support to some stuff that is now done very awkwardly in software.
The normal RISC-V memory model supposed cache coherence for the data caches, but makes the software deal with the instruction caches. That is a problem if you are running a JIT computer on one processor which is patching code used by other processors. This can be very tricky on processors like RISC-V which need a pair of instructions to jump to a random location.
If there are any suggestions of things that can be done to make Smalltalk virtual machines work better on RISC-V I would be glad to pass them to the group. I posted some ideas here back in 2018.
-- Jecel
vm-dev@lists.squeakfoundation.org
-
Bruce O'Neel -
Eliot Miranda -
Jecel Assumpcao Jr -
ken.dickey＠whidbey.com -
tim Rowledge