Skip to content
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

LabLang refactor #1080

Open
myreen opened this issue Nov 4, 2024 · 0 comments
Open

LabLang refactor #1080

myreen opened this issue Nov 4, 2024 · 0 comments

Comments

@myreen
Copy link
Contributor

myreen commented Nov 4, 2024

LabLang is an assembly style IL at the bottom of the CakeML compiler. It represents the program as a list of functions which in turn are lists of assembly instructions. The type of assembly instructions is shared among all target architectures (x64, arm8, risc-v, etc.). When LabLang programs are converted to machine code, each generic asm instruction is processed by a target-specific asm encoder function. These encoders convert each asm instruction into one or more target instructions before encoding each target instruction to concrete bytes of the targeted ISA.

There are several problems with LabLang but the most significant is that the compiler as structured currently has no IL where the program is a list of target instructions (as opposed to generic asm instructions). A list of target instructions could enable interesting target-specific peephole optimisations.

This issue is about redoing LabLang such that it is parametrised by the type of assembly instructions. When targeting arm8 the instructions should be instantiated to arm8 instructions.

There are also a few other clean ups it would be good to include in this refactor/rewrite of LabLang:

  • Only two-byte align function entry labels. Currently all labels are two-byte aligned.
  • Don't use a program counter in the semantics of LabLang; that was a mistake. Instead, treat the program as a list of instructions to execute; jumping to a label loads a new list to execute.
  • Make it impossible for functions to refer to each other's internal labels. It was a mistake to make this possible in the current semantics and that causes bloat in the compiler state.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant