I feel better now! Good to know this distraction eliminated. And I got some ideas how to get my programming language to work. I'll try to strick with the bytecode first and use in my own game as a scripting language. This is much more useful than thinking about how to export it to C code without maximum posible performance. And the more I think about it, the more improbable it becomes that'll "simply write a converter". My current point of view encourages me to not care about it as long as I don't need it. So I can concentrate on linking bytecode and C code during execution as well as designing the syntax. Make my live easier and less unforgiving (in theory). Yeah, some things take a long time, especialy those design-heavy (or maybe just the stuff that requires a lot of good interface choices, like a programming language for example).

I'm glad I sorted this out! I must admit the concept of a bytecode is a good idea for more interesting programming (provided that you can create bytecode during execution). I read some Wikipedia articles about it and think the easiest way for me would be to avoid everything that's register-based. Most code I write bases on modifying a set of similarly typed variables with the repeating instructions - mostly from an array or an adresse. So in all cases, can profit from that fact and design my bytecode in way that it's possible to a) execute a set of equal instructions on a sequentially arranged set of variables and b) implement this into the language or make some that's able to detect it. But since I'm not so good or event experience at writing such analysing alghortithms, it's easier for me to implement a new syntax element for it. Yes that's probaly a good solution: if you can't it like a "pro" and write complex compilers with a registers atomatically optimized functionality, then just specialize what you need it for.Would be cool if I could keep this in mind later, might come in handy.

Well, it's a bit uncertain if it comes to that. Executing a bytecode require conditional jumping and based on those jumps, execution of commands. I'm sure it's always worse to rely on only having the bytecode executer fast. You can't reduce the general problem of conditional jumping without making a short piece of machine code holding the stuff to do before execution a command sequence. This IS faster cause it's direct machine code and no conditional jumping. However, I can't do something like that. I don't even really know about assembler in detail and machine code really is higher stuff that's even creepier than assembler. So I can't design in such mechanics but rather taking values from adresses in memory. The cool thing is I can still design a to-C-code converter later and don't need to worry about it. Ok. Time to stop thinking about it too much. Haste makes waste.

No comments: