Maybe not as a bachelor thesis

I had opportunity to pick up my programming language again and actually came up with a perfectly stack-based solution for the bytecode and the parser, but programming would have beend so aweful and unformtable that I decided to go back to a simple procedural setup with parameter and function call. While doing this I totally revamped the whole concept once again, but this time with a seemingly fully functional concept. The point is that you can create great fast byte code when leaving out concerns about memory and variables. However, I can't program without them and I don't want to throw away all my experiences with normal programming anyway. So what I do have is a bytecode using a string-like memory address resolution system that can be used for static and dynamic code, making C-like program flow as possible as completely dynamically generated code you can put together during runtime with the same properties. This is a step as complete as I never had before during my concepts and it still is a concept after all. The syntax would look like assembler with some more C-like code blocks. Since that's a bit suboptimal (I'd rather want to write some mathematical expressions as well, too) I'm now free to add something on top, but the base will probably be the same. It's a good concept that can work less effort than concepts I had. Theoretically, one could also abuse it to call functions by string names - something I mostly dislike, but it can become quite useful in some situations. I got local variables, I got variables multiple levels up and also in completely other areas possible not yet beeing created. So whatever it'll result in, I got an acceptable byte code I now only need to generate from a custom syntax. I'll have to watch what a syntax to choose now. The point is that this whole concept doesn't know anything abou altering values or defining actual variable with specific types. The only thing iT knows are addresses! Yes, adresses. There's only call by reference and only the functions to call know what type should be behind. This enables whatever type to use and should provide broad compatibility with all kinds of types and programming languages as long as they are callable from C or wrappable. That said, there are also no real return values and thus a simple 'if' will also require a boolean variable before doing something. Wouldn't be too hard, but writing a compact code combining the 'if' function with the calculating function will require compiler-translated syntax rules and so on. Not sure how to continue there, but I guess I won't be able to choose thing as bachelor thesis as it is quite a lot of stuff I'll probably have to do for it to become something actually suitable. I'm really thinking about this right now and I hope I'll get a good idea in the future. At the moment I'll probably screw it all and wait for some idea to come in later. Currently, I better hurry continuing my game engine so I can show it off as a sign of my experience, so that I don't get some useless coffee job or so. I didn't really give my programming language as much love as it'd need lately and some day I want to start making more game stuff, too. So maybe as a master thesis. Well, atleast if my specialization will allow this. My university has only three specializations available and I guess I'll once again choose Multimedia due to obvious videogame-related reasons. It's all getting closer a bit too fast for my taste. Everyone needs to setup priorities. Mine should be videogames in any way. This is where the music plays.

No comments: