-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
running on arm #50
Comments
RISC-V would be another excellent target. In general, it'd be grand to see something like a nanopass approach that makes it easy to port... |
SubX is completely tied to x86. Since SubX is a very small subset or x86, it would probably be viable to translate SubX (possibly in one of the later stages of the SubX pipeline) to RISC-V or ARM machine code, but I feel like that is somewhat in conflict with the project principles. I'm not fully up-to-date on what Mu is like at the moment, but even by replacing everything "from Mu on down" things don't work out smoothly; for example Mu is currently tied to the x86 register names. As I said I don't really know enough about it currently to judge that, but there could be other deeper concepts (e.g. variables in memory vs in registers) that don't make sense the same way in a RISC ISA (where there are no addressing modes and load/store are explicit instructions). Because of this I've started to try to construct a parallel stack as an experiment, trying to port @akkartik's ideas onto the RISC-V ISA. We recently had a conversation in the fediverse about how (predictably) what intention I reconstructed from his writings is different from the goals he is working towards. I don't necessarily think this is the "right" way to do it, and I'm surely not going to arrive anywhere near Mu at the slow and sporadic pace I'm going, but it's a way for me to combine engaging with both Mu/SubX and RISC-V respectively, in a way that let's me get my hands dirty. |
I would love to have something like Mu on ARM or RISC-V. I've been looking for someone else to drive such a project, because I suffer from RSI, and my hands hurt too much with the typing for a single instruction set[1]. I'd love to support someone by brainstorming, or pairing while they type, or answering questions asynchronously. @s-ol has it exactly right about SubX. I don't mean to discourage a porting effort, just to inject a note of caution. I don't think SubX is a good enough general-purpose language to merit porting to other instruction sets, and there isn't enough Mu code out there for a port to buy you much leverage. I think a more interesting approach would be to design a transparent notation for ARM that can be implemented in machine code. In particular, providing good syntax for barrel-shifter operations feels like a really nice self-contained problem. With a little programming experience, you could probably build a prototype akin to mu/linux/bootstrap in 20 hours. Starting with whatever language you prefer. It's interesting enough that I've spent some time thinking about it, albeit without anything to show for it. The core of SubX is this skeleton:
What does a similar core for ARM look like? @s-ol Don't take my goals too seriously! Mu is an artifact above all for people to use as they think best. I really like this quote:
There's a very wide range of directions to take Mu that I would love to contribute significant effort to. As long as someone else does the typing. [1] This may be the single largest problem with the Mu approach: it takes a lot of typing, even with some simple autocomplete and swapping |
would it be worthwhile to target llvm-ir? then it'll be possible to use the llvm toolchain to generate arm/x86 code. |
I haven't thought about it much, but my immediate reaction is that:
Can you elaborate on what features you like about Mu that might make you want to do that? I wonder if you would prefer a subset of the Mu language that doesn't include registers. |
To be honest, until I saw your project. I didn't know os-less programming was even possible. My experience with low level programming is limited to a couple of MIPS tutorials so I don't really know how programs are designed in assembly. The thing that recently caught my eye have been the progress ARM made by TSMC (in collaboration with Apple, MS, AMD, etc...) and so I've been keeping my eyes open on tech related to hardware/software interfaces Personally, I've mainly working with transpiling from a clojure syntax to different languages (js,lua,python,c,sql): So something like:
gets transpiled to
Recently, I was playing around with transpiling to llvm. So
gets translated to
The same technique would work with So I'm not the right person to ask about features for this. But ideally, I'd want to be able to target ARM as I think it's the medium term future. |
So I downloaded qmeu and went though the linux/bootstrap code and the game of life code. Also, I went through your paper in the Portugal conference and did a bit more reading on instruction sets in general. I have some thoughts (which may be a bit off)
|
Thanks for all that detail! Yeah, this reasoning makes a lot of sense. Performance isn't really Mu's forte, and education is a pretty good niche for Mu. You're right, lsl/lsr/asr/ror may well be the way to go here. They're not the words I would use, but there's just 4 of them, and there's value in sticking with what others understand. I built SubX because x86 is a complicated mess. Perhaps the lowest level here should just be regular ARM Assembly syntax. It might actually be interesting to ask "the Mu question" of LLVM IR: what does the simplest possible language translating to LLVM IR look like? You may be under-estimating the difficulty of getting data out of Mu-on-Qemu. I don't have any device drivers yet for a network. I suppose you only need one, for either serial port or virtio. Perhaps that's the next step here. |
Hmm. For me, I really think that I don't think it's really necessary to be a full blown os like https://os.mbed.com/mbed-os/releases/ but to provide a kernel that you can boot up, interact with and then discard. It'd make for a terrific testbed environment for trying out new code. |
It could be some sort of low level scripting interface for qemu base systems. that would be really cool. |
The first question the simplest possible language has to answer is "why not just program one level below?" Mu has only one reason for existence: it is the simplest language I could come up with that's memory safe. That's why it exposes registers. I wanted a statement of Mu to map to a single instruction of machine code. Here's a summary of Mu's translation table: http://akkartik.github.io/mu/html/mu_instructions.html Interacting with hardware might be a second good reason. The problem: I'm not an expert at interacting with hardware 😄 So we'll see how things evolve and how much I'm able to learn. |
Yep. Got it. I think it's safe to separate out the language (format + packaging) from the runtime. Here are some questions/comments I have for both: Runtime
Language
(compile '[:add r0 r1] :arm)
=> source code
(compile '[:add r0 r1] :x86)
=> <<ERROR, use eax instead or r0>> Again, I just think there's a whole bunch of overlap between mu and llvm. It would be interesting to figure out how much overlap there is. Here are some docs covering the instruction set. It's pretty dense but I'd like to get your thoughts on which concepts are mappable between them (LLVM must already be doing something like this internally). https://llvm.org/docs/MIRLangRef.html |
would something like this be useful: https://fctorial.com/posts/parse_struct.html? |
I don't quite follow how that link is relevant, but perhaps a port to Clojure will help clarify it. The Mu translator at mu/linux/mu.subx is not an interpreter but rather an almost trivial compiler. All it does is translate Mu from stdin into SubX on stdout. There's no new VM instruction set, it's just all x86. I am interested in some sort of JIT capability, because it'll be needed to translate and run Mu from within Mu. Right now you have to reboot in between. The major obstacle is Mu's lack of any notion of process. |
That's exactly right. LLVM is already essentially this abstraction:
So depending on your goals, just using it instead of Mu may be an option. |
@akkartik Yep. That makes sense. I'm gunna stick to LLVM IR. I think there may be a simplistic way to achieve something resembling Thanks for the clarification regarding the project and all your inputs. Things make a lot more sense now than before. |
that link was a clojure project - see https://fctorial.com/posts/parse_struct.html#arealworldparsingexample I thought that maybe someone clojure inclined who might want to build a disassembler for |
What you could consider is to gut out the functionality you need in an interpreter project like https://github.com/kanaka/mal/tree/master/impls/cpp and adapt it to |
The problem is that Mu doesn't have ELF binaries to disassemble at the top-level. Another relevant-looking project that just popped up on my radar: https://github.com/oneOS-Project/oneOS. I think Mu will need some of the foundational features this provides before it can provide the sorts of things you're thinking about. |
wow. that project's impressive. its implemented its own libc and the entire stack. having some of the lower lever features would be great. |
A disassembler may still be a good idea, even without debug information. I think it may be equally easy to store the sources in the disk image. I'll keep both options in mind. Thanks! |
Re qemu scripting - I found this: https://github.com/Comsecuris/luaqemu |
and this - https://www.unicorn-engine.org/showcase/. it's an entire ecosystem. |
I'm just curious if mu can be potentially be targeted for arm processors and how much work that might take.
The text was updated successfully, but these errors were encountered: