So, I'm currently writing a kernel in x86_64 assembly, following in the footsteps of Henry Massalin as I once so neatly put it. I'm just about to start on the queue quaject (multithreading, paging, usermode, etc. is done), but it strikes me that the fasm macro-language is too restricted, and doesn't easily allow for certain advanced code-size reducing and code-speed enhancing features. So I'm considering making my own macro-language for it, and I think this would greatly enhance the maintainability, modularity and awesomeness of the OS. Macros would be written in the source-files in a Literate Haskell-ish fashion.
The most obvious to me would be relocating each modules' initialization code to right after the CPU-initialization, allowing that space to be reused as data-area when stuff is up and running. I would also consider having automated register renaming ('1' => 'd' makes r1 map to rdx, r1d edx, r1w dx, etc), but automated register allocation would be pushing it.
Also, as the preprocessor would know a lot more about the procedures and their register consumption, the task of saving and restoring the registers could be automated for syscall routines, as it becomes some kind of reflection. If I'm really good it could even become type-safe.
Does this sound like a good idea? The reason for not just writing it in some other language is that I'm wholeheartedly convinced that I can make a faster and better system than any compiler. Also, which language would be best to implement this in? Right now I'm leaning towards python.
Will your macros need a full blown parser or can you get by with regex?
Name:
Anonymous2009-03-16 22:37
>>5
I was thinking a special syntax, like every line starting with a : specifies a call to a python «macro» that does whatever it's supposed to do on the following code-block (delimited by FIOC). All the definitions are extracted beforehand by the would-be python-preprocessor and loaded before it goes through the transformation phase.
The python-macros would be written on lines starting with >, and maybe take a string or a tokenized stream as an argument, along with any arguments to the macro, that it then returns when done operating on it.
As pure ASM is shit-easy to tokenize this shouldn't be be complicated at all, and if it does get hard I'm armed with my dragon book (that I haven't read yet, so excuse me if that is the wrong usage of the word tokenize).
The reason for not just writing it in some other language is that I'm wholeheartedly convinced that I can make a faster and better system than any compiler
Lol wut? Compilers do not make systems. Language compilers are a system of computer programs that translates human readable computer code into machine executable code.
Name:
Anonymous2009-03-17 1:42
Write it in C like most people who code kernels for OSes. If that is not to your liking, code it in a language you find more suitable and code your own compiler for it, you can add as many code optimizations as you'd like, it will also be more portable, and better usage of your time. Code hardware specific parts ( I don't mean drivers or such, but actual input/output instructions and instructions for manipulating descriptor tables, paging, exception handling ) and parts which need really high speed in asm, you usually don't have too many of these and they can be isolated and linked in easily.
>>7
Doesn't do what I need. >>8
Some day. >>9
s/system/code/, I guess. >>10
No, at least not yet. The point of the project is to find better ways to do stuff, and then perhaps later make a language capable of using them. Making something in a boring and done-to-death way is too pointless when combined with making something nobody's going to use beyond booting it up in a virtual machine and thinking “that's neat”.