chalk-os/rustboot
1
0
Fork 0
Code Issues 2 Pull requests Projects Releases Packages Wiki Activity Actions

Figure out how we support real realmode codegen #2

New issue
Open
opened 2025-05-06 18:16:12 +02:00 by mai-lapyst · 1 comment
mai-lapyst commented 2025-05-06 18:16:12 +02:00
Owner
Copy link

Currently the code generated by the rust target for the bootsector of bios boots is using size prefixed 32bit instructions to work in 16bit CPU mode. This should be changed.

For this there are two ideas:

  • Post processing the rust output (either by asking it to output asm and just rewriting that or by byte juggeling)
  • Changing LLVM to emit true 16bit code when asked nicely (or not-so-niecely)
Currently the code generated by the rust target for the bootsector of bios boots is using size prefixed 32bit instructions to work in 16bit CPU mode. This should be changed. For this there are two ideas: - Post processing the rust output (either by asking it to output asm and just rewriting that or by byte juggeling) - Changing LLVM to emit true 16bit code when asked nicely (or not-so-niecely)
mai-lapyst commented 2025-11-17 07:01:13 +01:00
Author
Owner
Copy link

  • processing bytes; this would be fairly complex since it also would either involve detection of pointers to itself and modifing those. We theoretically could our (already existing) custom toolchain definition to use an custom linker binary that modifies the elf before the linking step, but ELF has no notation of 16 bit code so a linker wouldn't work here. And thats just for the non-inlined functions. So we're back at square one for all inlined stuff.

  • processing asm; better, but would force us to actually parse and assemble 16 bit assembly; could look for one out there tho...

  • changing llvm and rustc; completly out of scope. I tried it, it works (somehow) but I'm just to unknowladged in llvm internals, it's tablegen and instruction selection etc. Also rust needs to be recompiled and this takes a LOT of space and time. Not to mention how to integrate it with the CI... so its a hard no unfortunately.

- processing bytes; this would be fairly complex since it also would either involve detection of pointers to itself and modifing those. We theoretically could our (already existing) custom toolchain definition to use an custom linker binary that modifies the elf before the linking step, but ELF has no notation of 16 bit code so a linker wouldn't work here. And thats just for the non-inlined functions. So we're back at square one for all inlined stuff. - processing asm; better, but would force us to actually parse and assemble 16 bit assembly; could look for one out there tho... - changing llvm and rustc; completly out of scope. I tried it, it works (somehow) but I'm just to unknowladged in llvm internals, it's tablegen and instruction selection etc. Also rust needs to be recompiled and this takes a LOT of space and time. Not to mention how to integrate it with the CI... so its a hard no unfortunately.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Blocks
#1 Support bios that expect a BPB being present
chalk-os/rustboot
Reference
chalk-os/rustboot#2
No description provided.