- RISC-V 64bits assembly (using binutils gas and no pseudo-instructions), but running on x86_64 with a RISC-V 64bits machine code interpreter and a linux syscall translater. Using a C preprocessor (currenty tinycc one), reducing to minimum the usage of gas pre-processor. Have already partial/bootstrapping implementation of the interpreter and syscall translater.
- would use RISC-V 64bits non-ratified ZACAS synchronization emulation on x86_64. Care will be taken for synchronization primitives to allow ez swap with other synchonization primitives (once going on real RV64 hardware).
- no libc
- new executable file format (orders of magnitude simpler than ELF), but with an ELF capsule to run it transparently on any linux kernels (the glibc/musl/etc elf loaders should be able to load in the ELF capsule directly too). Have minimal/partial/bootstraping linkers (ELF objects from compilers/assemblers x86_64/rv64) already (can handle some C code from cproc/qbe toolchain).
- probably basic window stacking in the first place, one seat.
- may copy some code from mesa for vulkan3D like hardware acceleration (for AMD GPUs) but may use rv64 "custom" machine instructions to run x86_64 accelerated CPU rendering. Will have to go for affero Lesser GPL for licence to fit with MIT licence without issues.
- still dunno if I go inotify on /dev/input or kernel events for dynamic management of input devices (any advice anyone?).
I dunno if I'll be able to get something working, and that in a reasonable amount of time. And if IRL gets annoying, may have to drop it, of course.
The new new plan: C99-ish (able to compile with other compilers than gcc and clang) implementation using drm vulkan display support from mesa.
Once something is working "enough", start to port libdrm then mesa to the new executable file format (as usual c++ code is going to be the issue... still some people thinking c++ makes them smart and not toxic as f*ck for the humanity).
- linux kernel, getting ready for 2MiB system memory page.
- direct ioctl DRM (which means I may need AMD GPU specific code, my developement hardware).
- dma-buf (like valve steamdeck wayland compositor).
- linux evdev (input)
- RISC-V 64bits assembly (using binutils gas and no pseudo-instructions), but running on x86_64 with a RISC-V 64bits machine code interpreter and a linux syscall translater. Using a C preprocessor (currenty tinycc one), reducing to minimum the usage of gas pre-processor. Have already partial/bootstrapping implementation of the interpreter and syscall translater.
- would use RISC-V 64bits non-ratified ZACAS synchronization emulation on x86_64. Care will be taken for synchronization primitives to allow ez swap with other synchonization primitives (once going on real RV64 hardware).
- no libc
- new executable file format (orders of magnitude simpler than ELF), but with an ELF capsule to run it transparently on any linux kernels (the glibc/musl/etc elf loaders should be able to load in the ELF capsule directly too). Have minimal/partial/bootstraping linkers (ELF objects from compilers/assemblers x86_64/rv64) already (can handle some C code from cproc/qbe toolchain).
- probably basic window stacking in the first place, one seat.
- may copy some code from mesa for vulkan3D like hardware acceleration (for AMD GPUs) but may use rv64 "custom" machine instructions to run x86_64 accelerated CPU rendering. Will have to go for affero Lesser GPL for licence to fit with MIT licence without issues.
- still dunno if I go inotify on /dev/input or kernel events for dynamic management of input devices (any advice anyone?).
I dunno if I'll be able to get something working, and that in a reasonable amount of time. And if IRL gets annoying, may have to drop it, of course.
Yes, I am greedy.