Hello, all. How is going and what-not? I am coming to you through the tried and true magical internet textual format as opposed to the video alternative due to computer speed concerns (built from spare parts a 2-core 3.6-Ghz 4gb rig to just edit text on Windows 10, what strange times we are in, considering that is somewhat necessary). Anyhow, instead of watching me implement, today we shall be discussing the implementation of C++'s object functions and how seashell shall be interacting with them going forward, along with considerations on the parser implementation and a piece of the other programming thing I am working on.
Firstly, the simplest way to implement an object function was followed through in what seems to be most compilers. Just passing a pointer to the object as the first argument to the function in question and using that to address the members is apparently the common style (~ 'this'). Interestingly, because this implementation happens to be so very simple, we were able to achieve a full degree of functionality with a low degree effort (there was some confusion with old stuff that has gone unused and screwed with output). In C's style, a large return size forces a pointer into the x64 register rcx, and this forces the first argument into the following register rdx instead. Thankfully, in this most important case and all others, the simple abstraction we originally mentioned, the consideration of the object in question as the first argument, is successful. Thus we are to expect that the only work that needed to be done was a bit of checking and a custom call (I'm currently using 'ocall' as the in-shell command), which is close to what transpired. So thus, for once, we can thank compiler implementors for not being insane. That said, handling templated versions of the function is beyond any sensation of reasonable.
On the other side, the parser currently is beyond my idiotic reach. When I left for vacation, I so dumbly left the text file on my hard drive despite loading many other projects I was working on into a google drive. As the kids say: "derp". Despite that, I can share some thoughts regarding what it was like upon my departure and what it will be like upon my return to working on it. When I left, it essentially loaded global variables by going byte-by-byte and noticing characters like ',' and ';' to reverse-parse into a variable and its type. It did no checking and only cared to see these characters when they where not in brackets or parenthesis. The case of previously-opened parenthesis of the first magnitude is the case with which we are concerned for our recognition of functions, and the alternative of brackets following a "typedef struct" is the same but for types. Two problems arise: for the function case, disregard semicolons as under our parsing concern; for the type case, simply outputting on every comma or semicolon is insufficient, we will likely have to gather a list and output all at the end, but may be able to escape such complexity given how seashell handles the strings input into it. The goal for this software is to one day be run as a preprocessor which outputs C to be included into a main function, and as I am sure you understand, order counts for types and the like given seashell's internal checker. I would prefer to simply give types, vars, and then funcs in the file for simple legibility and guaranteed checker acceptance, yet the current model of text-streaming is insufficient for randomly-injected C projects. I do think, however, that three streams of text banded together would be a fine solution, and that is likely where we shall head if or until it fails to give desired results.
Otherwise, another project is still in the works (I know I keep saying its soon, but I guess I don't know what time is). It is roughly a workflow I wish to adopt for specific projects going forward, and this is all I can generally say. Specifically, however, I can say a bit more. In order to complete the project to the degree of functionality I desired, I required a x64 byte compiler from an assembler-like level. Instead of doing the sensible thing, I decided to write my own for experience and fun reasons. The latter was not achieved until the end of the ride, and thankfully it now (mostly) works. I would like to release it as a separate component one day, because it does its job pretty clearly and attempts to generalize and abstract some of the design of x64 (which is a rather strange bytecode, believe me). Moreover, the level it represents is assembler-like and can be output bi-directionally to gcc asm or bytecode. Yet, it is lower-level than assembler yet higher-level than bytecode and can be handled as a defined, structured type in C. I am sure that other implementors like intel did something along these lines, because it appears very useful and relatively simple compared to alternatives (like an asm parser, which is not hard but harder than this, and could even be baked-on-top this thing for a complete assembler). It notably does not implement the complete specification, just the part I think is useful (which is tiny; yay we might not be using space wisely!). Also, I would not consider the implementation as it currently stands 'optimized', with the reason for that being I needn't a fast byte compiler for my purposes (that will maybe confuse as to the nature of the project, but it is a serious hint).
Finally, hope you have a good one. Thanks for reading this short article of increasing depth in computing, maybe sometime I can author a more analytical piece of greater intrigue and value.
--Grant T (@eternal_salmon)
P.S. Is it just me, or am I a lot more serious in textual form?