investigate replacing in-source macro-assembler with masm-rs

[soc]

If the library provides comparable functionality, it might make sense to get rid of the in-source masm in favor of masm-rs.

A stand-alone library like masm-rs might attract more people/users from different languages/backgrounds, thereby lessening development and maintenance burden.

Ping @playXE.

Tentative 0.6 milestone for coming up with the kind&amount of work required to port Core to masm-rs.

[playXE]

Hello! masm-rs still does not yet have SIMD and arm64 support. While SIMD is not required to run Core or Dora I think ARM64 is more or less "must have" feature? I hope to start work on ARM64 support in a few weeks once my M1 Macbook gets repaired :D

[soc]

@playXE amd64 is fine for me at the moment, I guess arm64 support could also be taken from this repo, if that makes things easier?

I'm more likely to get some RiscV device than ARM hardware, so that would be my interest afterward. ;-)

[playXE]

ARM64 will be taken from JSC as well as they implement branch compaction and code patching there. :)

RISC-V also can be ported from JSC but it requires for me to get some way to run on it, maybe chroot? Btw, have you thought of using B3 to get full backend instead of baseline JIT?

[playXE]

UPD: I found out about https://github.com/cross-rs/cross. Will start work on RISCV64 right now :)

[soc]

ARM64 will be taken from JSC as well as they implement branch compaction and code patching there. :)

Ah, interesting, good to know!

RISC-V also can be ported from JSC

I didn't know they had RiscV support already, that certainly simplifies things.

it requires for me to get some way to run on it, maybe chroot?

I'm trying to get my hands on some VisionFive2s, I'm happy to order one for you too if you want some real hardware to play with.

Btw, have you thought of using B3 to get full backend instead of baseline JIT?

No, not at all, but I plan to have a look at B3 and what it does.

I'm currently heavily focused on getting the language into the right shape; I believe I'm sadly quite some time&effort away from having bandwidth for backend considerations.

Basically, at the moment I could tolerate the worst, single-target backend I can get away with as long as it allows me to run my language experiments.

[soc]

@playXE as a background: My plans for the language are here. The language is meant and designed to be "done" at a not-too-far future, in a stark contrast to most other languages that keep "evolving".

[playXE]

I'm trying to get my hands on some VisionFive2s, I'm happy to order one for you too if you want some real hardware to play with.

Funny thing is, I pre-ordered one from kickstarter but it arrived in Uzbekistan two months later after I moved from it to Georgia and I can't get my hands on my one :(

No, not at all, but I plan to have a look at B3 and what it does.

B3 does register allocation and some simple opts for you. :) With -O1 you will get slightly better code but a little slower compile times, with -O2 you will get much better code at the cost of slower compile times. But since the architecture of a runtime uses lazy compilation this should not be a problem. I am planning on doing lazy compilation with -O2 in my Scheme compiler

[soc]

I can't get my hands on my one

Let me know if there is anything I can do to get one to you!

register allocation and some simple opts

To be honest, I don't even know that well what's currently happening in this code base, so I haven't any kind of opinion on the implementation itself (only that I'm not just going to copy "whatever C does" in terms of conventions). :-)

[playXE]

Let me know if there is anything I can do to get one to you!

I probably could just order another one myself but thanks. :)

[playXE]

@soc by the way, are you in PLD discord server? I think it would be easier to communicate there :D

[soc]

I think so, I'll search you there! :-)

[soc]

For now, core has its own RiscV backend now, and while functionality may be comparable to masm, I prefer the current macro-less implementation.

Let's close this for now, and re-open when there are substantial changes that warrant revisiting this decision.