From 6df6dce1531a65b887963cb0fc19f2f976b21f8b Mon Sep 17 00:00:00 2001 From: Aryadev Chavali Date: Tue, 9 Apr 2024 15:00:59 +0630 Subject: Added todo to force an endian convention I've flip flopped a bit on this but I believe the virtual machine bytecode format must have a convention on endianness. This is because of the issue stated in the TODO which may very well happen. --- todo.org | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/todo.org b/todo.org index 9a4859a..ba3f0f0 100644 --- a/todo.org +++ b/todo.org @@ -15,6 +15,24 @@ *** TODO VM [0%] **** TODO vm/runtime.h ** TODO Specification +* TODO Rigid endian :LIB: +Say a program is compiled on a little endian machine. The resultant +bytecode file, as a result of using C's internal functions, will use +little endian. + +This file, when distributed to other computers, will not work on those +that use big endian. + +This is a massive problem; I would like bytecode compiled on one +computer to work on any other one. Therefore we have to enforce big +endian. This refactor is limited to only LIB as a result of only the +~convert_*~ functions being used in the runtime to convert between +byte buffers (usually read from the bytecode file directly or from +memory to use in the stack). + +2024-04-09: Found the ~hto_e~ functions under =endian.h= that provide +both way host to specific endian conversion of shorts, half words and +words. This will make it super simple to just convert. * TODO Preprocessing directives :ASM: Like in FASM or NASM where we can give certain helpful instructions to the assembler. I'd use the ~%~ symbol to designate preprocessor -- cgit v1.2.3-13-gbd6f