RFC 0014: CHASM Processor

[Pyrofab]

This RFC describes the details regarding the processor component of the ASMR CHASM system outlined in RFC 3 (#3). This document is still far from done, and will have to be kept updated as the design for the overarching system evolves.

Implementation design is based on the ASMR Processor Prototype by Earthcomputer.

Rendered View

[marshoepial]

I don't think there is any inherent downside to allowing modders to implement transformers on their own. As long as each transformers' writes are checked against the reservations they made during the read phase, there shouldn't be any issues with conflicts arising from badly written custom transformers. Something like a wrapper or handler for org.objectweb.asm.tree.InsnList that has those checks should be fine, I think.

And of course if the bytecode is malformed, then that would be on the JVM to check.

[Earthcomputer]

The problem is, badly written transformers might not conflict when you might think they should, with the current design. The ASMR backend has a fair amount of manual conflict detection, on top of automatic conflict detection. I'm thinking of either changing the backend to force you to always specify what type of conflict detection you want, or making the backend harder to write in directly.

[darkerbit]

New name for ASMR from the 26.06. developer meeting: CHASM, short for Collision Handling ASM

[sylv256]

has this been finalized + what needs to be done to get this merged?

[anonymous123-code]

This seems rather outdated (especially the JVM bytecode part, chassembly exists now)