-
Notifications
You must be signed in to change notification settings - Fork 201
Port the DSL to Rust #342
Comments
Implementing this in Rust seems like it would be nice, given that the rest of the codebase is in Rust. At least from afar, I can't think of any reasons that would make switching to another language similar to Python beneficial. Whatever is chosen as the direction forward however, happy to help out with this 😄 |
Thinking about this more, I think using Rust, with a build.rs approach, is the best one right now. So as I mentioned above, I think gen_types.py is a good initial goal. And looking at it more closely, gen_types.py depends on srcgen.py. And, srcgen.py is a very simple file that should be very straightforward. So the very first step here is to make a Rust version of srcgen.py. It's a simple file that just makes it easy to produce Rust source code, managing things like indent levels. @data-pup Are you interested? :-). |
I'm in, that sounds fun! I'll start looking into this, and I can follow up if I have further questions. I'll keep you posted in IRC too :o) |
Woohoo! The first step, #403, is now merged! The next logical step is to look at the compiler settings, and in particular https://github.com/CraneStation/cranelift/blob/master/lib/codegen/meta/base/settings.py shows what settings are all about. Note that @data-pup How does this sound to you? :-) |
I can start looking into this further this weekend, but that sounds good to me! I'll let you know if I have any further questions about that 😺 |
Procedural macros are stable now. (Or will be soon). It looks like you can define a procedural macro, but not import it yet. |
I think the plan is definitely to move towards procedural macros in the future. Currently however, cranelift supports 1.25, which I do not believe would support this? @sunfishcode would know more regarding that, but currently we'll have to work around that :) |
That's right. However, if there's a major advantage to switching to procedural macros now, let's talk about it, as we may have options. |
Ok, after experimenting with several approaches with The next step here is the settings.rs file, which @data-pup expressed an interest in. |
🎉 Yay! Glad we've figured out the publishing thing. I've started looking into the |
Another way to do this would be to use a dynamic language like |
Hey @data-pup, I'd like to help on this issue, but I wouldn't want to step onto your toes. Are you still working on the settings.rs file? Or have you been working on other files? If not, I'll start migrating other stuff, and will make sure to announce it here first. |
Hi @bnjbvr thanks for checking in! Feel free to start working on this. I have been a little caught up with life things the past couple weeks, and would happily let you take care of this if you have the time :) |
Thanks for letting me know! I'll try to work on the Registers now. |
Work on registers has landed, and there's now basic support for multiple ISAs! I'll now work on settings. |
Settings have partially landed (they're blocked by instruction recipes which use unnamed ISA predicates). For what it's worth, unless somebody else has started work on this (in which case it'd be nice to show up :)), I'll be working on the rest of the DSL migration to Rust. I am not sure it is easy to distribute this work now, because all the remaining concepts seem to be entangled in some ways (although I suspect there's a subset of code related to binemit that can be migrated separately (Encodings etc), which is what i'm working on now). |
Maybe port one part to rust and add code to write the original python for use by meta-python. Eg. port |
That's a great idea! That being said, with the recent progress (TypeVar, Operand, Instruction, InstructionGroup ported), it might be as straightforward to migrate the rest in a few steps directly. My understanding is that the following order is possible:
I'll be now working on legalization actions and generating them; if somebody is interested in porting recipes, please let us know here so we don't duplicate work! |
I would like to do it. |
That's great to hear, thank you! If you're not afraid of rebasing code, I'd recommend basing your work on top of #694 (last part of the Instructions port), or even wait for it to be landed to minimize bad rebases. There's some code that might be redundant with respect to CpuMode and other stuff, so we can:
Any preference? Happy to discuss this in real time over irc (#cranelift on irc.mozilla.org). |
+1
|
Sounds good to me, cheers! |
I'm now focusing on this. If anyone is about to implement a new architecture, I'd strongly advise to wait for this to be finished first. I expect around one month of work on this topic, considering the time it took for the previous parts. |
…ecodealliance#342 Co-Authored-By: bjorn3 <[email protected]> Co-Authored-By: Benjamin Bouvier <[email protected]>
Fixed and landed! |
I will be good to release a new version after this change. |
Cretonne's Python-based DSL allows target ISAs to be described in a concise manner, and can generate tables, code, and documentation from them. It's common for compilers to use DSLs for such purposes; see also LLVM's tablegen, GCC's machine description language, libfirm's perl (example) and python (example), and others.
Python compares pretty favorably to obvious alternatives, in particular by being a real programming language, and a fairly friendly one at that. However, using Python in Cretonne has some downsides too:
__getitem__
,isinstance
, etc. which may be fine for people who work with Python regularly, but which make it harder to follow the code for people who aren't.PUT_OP
in the x86 target. It's used in Rust code, but it's not a Rust construct; it's edited out byreplace_put_op
. In some cases, it's replaced byput_mp2
, but it's not easy to determine when that name is used, as there are no other occurrences ofput_mp2
ormp2
in the repository. As another example, the DSL infers instruction formats from instruction fields implicitly, in a way that makes it confusing when one is adding a new format and accidentally colliding with an existing format.None of these are show-stoppers, and one option is to just keep the current code and refactor it to help out with some of these issues. But we should also consider where we want to be in the long term; it'd be easier to do a large architectural change now, while the code is (relatively) simple, as it'll grow more complex in the future as we add more features. One option is Rust's procedural macros, except that they're not yet stable. A possible intermediate step could be to use a build.rs.
The instruction descriptions are fairly elaborate, so one way to start experimenting with this would be to start by rewriting some of the simper parts, such as just
gen_types.py
, to get started setting up the infrastructure.gen_types.py
's output file is target/debug/build/cretonne-codegen-*/out/types.rs, which is pretty simple and demonstrates what it does.If anyone's interested in working on this, I'd be happy to mentor.
The text was updated successfully, but these errors were encountered: