4.28.2011

Better than computer in computer

Screw this with the Computer in Computer idea, I've got a better solution. I figured that all this stuff with virtual hardware components can, in normal C or C++ programming, be replaced with some simple classes of course. Too bad you need to recompile it. So I asked myself: How to connect modules with the bytecode execution? How to get of recompiling the bytecode executer everything you want to add another module? It hit me like a slice of lemon wrapped around a gold brick: dynamically loaded libraries. I can remember that, in the first programming language I ever wrote, I used a command to load and assign a DLL file to a name. You could simply prefix the name followed a colon and add the desired function. This simple system allowed the user to randomly call functions by the names found inside the DLL files. Since the library I used for it simply pushed parameters on the stack, I think it's save to assume that they were loaded directly to RAM and then called with no big performance deal. Some people found it pretty cool and now I see where it fulfills it's role in my next programming language. So I can screw the whole instruction set/hardware system and represent everything as a dynamically loaded library. I don't how this is archievable in Linux architectures and how I can keep this system portable, but I can image some cool things using this. But still, every command would be a function call. When exporting to C code I better replace them with actual C code instead of function calls. I think I can solve this using special funcs in the DLL, too. Who knows. Let's see how this is going under Linux and Mac OS.

No comments: