It's amazing what awesome instructions there are in modern CPUs. Stuff like Multiply-Accumulate (MAC). If that's really associated with the listed formula, it might be the most awesome thing ever for doing alpha blending, mixing signals and so on. Really fascinating! I see, inline assembly IS useful to me and if I don't find any demanding occupation during my study time, I'll write libraries for specialized functions I can then use within my own bytecode executer. So far, I really like the idea of a language that's more a handler of addresses and dynamically loaded libraries. This way you can add interesting functionalities other than the typical set of high-level programming language. I always prefer using more simply languages that don't hide what's actually happening. If you know a lot about C and C++, you know what the compiler with and without optimizations. But you WILL need to know about this and that's imho a wrong way to teach people programming. Of course, not everybody wants to full throttle. I respect and understand that! But if you're studying informatics, I think it's important to first get a feel for what's under the hood and then decide whether you want to hide the actual process or not. Well, I'm totally biased in that case. You know, I'm a rather "classic" programmer who learned procedural language and didn't use ANY comftable toolset cause I didn't like them and saw how they miss stuff I really wanted. However, it's just too fascinating to see what awesome instructions lie in our everyday CPUs! Compiler optimization blabla - if you know what you want (and know that you want ONLY THIS), then you'll surely profit from writing inline assembler code inside your program.

Hm, I guess it's also possible to write real assembly code with my language concept... Simply include the corresponding library that's detecable by the to-ASM converter and it translates to a matching assembly syntax. Not too bad! I can imagine this project becoming simply awesome. Or one could write a converter detecting both C and assembler functionality and then combine them using c files and inline ASM! Quite a cool idea. But that's writtin in the stars (or atleast in the major plan for traveling out of the sun system) there's still an interpreter to write, the main functionality. I think it's best to also parallely write some high-performance image mixing libraries. You don't need any special vector operations for that except 2D and I'll definitely want to experiment whether those specialized MAC instructions perform better than conventional ones. It's exciting to think about the possiblities that may be possible generating bytecode that's using those assembler instructions in the way you told it. Imagine that: custom, generated code written in the same you'd write optimized ASM code! That's far cooler than auto-optimization or mathematical notation inside the syntax. So to get a feeling for that, it's prolly way better to first use and study what's possible and then assault with full force. Well, why don't just completely write the final bytecode converter so that it exports to ASM? I have GCC, I have instruction sets and I know about calling conventions. Those calling conventions are flesh and bone of my language design so far - some libs call functions, some get translated into code directly. Simple seperation, easy management. So know we're talking about custom programming languages, right? There are so few necessary commands, I bet it's a cakewalk to convert this simple program to assembler code cause in the core variant it only consists of function calls. All those local variables things and so on... That's just memory at all. The only difference as far as I remember is that there's a fixed memory size inside the assembly for contants, global variables etc and nothing more. Malloc is my friend I guess. The standard C libraries could still be used this way, simply use their binaries. Yeah, pretty much how it should work. I believe that's the best path to take: more indepth learning, more knowledge and ultimately a true challenge to improve the world of programming languages. And the best is that with bytecode generation is that one can, depending on the target platform, decide what library to include and what instructions to put behind certain functions. Well, isn't that concept a compiler? I think so. Seems no real difference to any other.

No comments: