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