holyc-compiler icon indicating copy to clipboard operation
holyc-compiler copied to clipboard

What is the current progress of this project.

Open allbombson opened this issue 3 years ago • 4 comments

Hello I'd really like to know the current roadmap and progress of this project. Judging by what code ive read you dont even run your tests or fully understand some parts of the c language. Also by looking at the programs in your Tests folder i see you dont use any includes, is this a mistake? becuase like if your trying to use no includes just like HolyC your kind of fucking retarded. TempleOS is jit and everything is linked to pretty much everything. This doesnt make much sense in a modern OS env it would end up leading to crazy large binary. There is a bunch more too that ive noticed as well. If you wish to talk to me privately my discord is allbombson#4979 and i can hopfully explain more there.

Cheers, Thomas

allbombson avatar Jan 18 '21 17:01 allbombson

Hello thanks for raising this concern. The current state of the project is that I was taking a bit of a break whilst I work on one of my other projects whilst until I get burnt out on it then I will switch back here and vice versa, this is just how I work on code.

'Also by looking at the programs in your Tests folder i see you dont use any includes, is this a mistake' I am going to assume you mean the #include file. Yes I know that I have not used any but dealing with functions and conditionals when first doing the parser was enough that other key features were not a priority until more basic features were in.

'TempleOS is jit and everything is linked to pretty much everything' The compiler in TempleOS is a jit and I know of that. My plan was to first write a very basic HolyC compiler without any jit, just a basic one like gcc then go and write a new jit compiler using the basic compiler, essentially rewrite the language in the language.

'even run your tests or fully understand some parts of the c language' If you mean having a unit test C binary being made for all the .HC files in Tests/**, I know that there are lots of files in that folder which were not intended to be run as a unit tests but were made when I was doing the input stream parsing as the lexer was not stripping tokens correctly. Additionally the build tests in HolyC-Tools/Tests do get run by RunTests.sh which I am planning to change as I did figure out that cmake has a feature to run binaries if you compile a makefile with make test

There are some issues with the code but I am just 1 person with other projects aswell and I have been more focused on those for the last month but I do plan on putting more attention on this project soon. I can message you if you want to discuss further

Alistair-Bell avatar Jan 19 '21 09:01 Alistair-Bell

Hey thanks for responding! I understand that burnt out feeling it happens to the best of us. When I said "fully understand some parts of the c language" i was more refering to some of the code I had looked at. I have a tiny little Holy C, C libary that ive been porting some funcs to for use in my own projects I havent publiclly published it yet tho bc its a bit of a messy WIP. Now my understanding assembly is not the best but from what I can tell a few examples are like in strlen: you get the argument from the stack by doing popq %rax but then you push it right back onto the stack when all of that could have just been done with movq (%rsp), %rax. Another example is in your PutChars function. I dont know if your aware but PutChars actually prints 64bit intergers in little edian that can contain up to 8 chars (This is one of the functions that i had ported over) While you just print a char array to stdout (Again not that well versed in assembly correct me if im wrong) There are a few more issues that I think there are in the assembly but I wont bother putting them all here yet. Another thing is some of the C code. In common.h you seem to hardcode a few of the HolyC data types for x86 This is an issue if you plan for this to work on other archs. Now the actual issue with hardcoding these is that the signage of a type is defined in the C lib and not the C standard meaning diffrent C lib implementiaons could make shit unsigned by defualt. This is why stdint was created. Another thing is that you define I8 as char but due to the fact above signed char and char are treated diffrently. The idea is the c lib could define char as signed or unsigned depending on the OS's encoding. My sulution to this was simply to add a type called C8 in my lib that is typedefed to char. Ofc the sizes of these are also up to the clib hense why stdint exists as ive already stated. Now including stdint comes with the cost of including that header of course so in my lib i have a macro to go back to hardcoded typedefs. Another issue with this header is the fact your including other headers. What is the point of this? are they really needed? from my understanding this is horrible practice. It also should go without saying that a lot of features of HolyC only make sense in templeOS but I don't think now is a good time to go into that list. I aplogise if I seem rude I just wanted to make you aware fo these things and possibly help out if I can.

Cheers, Thomas

allbombson avatar Jan 19 '21 16:01 allbombson

Hello Thomas, Thanks for getting back. No need to apologise for being rude I understand where you are coming from and I appreciated raising some concerns with the code. The assembly part of the code I agree needs some real work, personally I am not that great with the language and still relativly new so the code is poorly written which is a consequence of my inexperience. The idea of the Common.h header is to act as an easy way to include required headers, define universal types and macros which the whole project requires in one place therefore another header could include it, reducing the amount of times I would have to #include <stdio.h> etc. Additionally as all files in the Core-Backend part of the code would include the one header and it would allow me to precompile it, reducing compile times of the whole project which is always a bonus. The code has some core issues which now I have taken a break from this project and came back to it, these will be adressed and I thank you for bringing attention to some flaws which impact the project. In the next day or two whilst I familiarise where I got up to I will compile a list of stuff needed to be done in order to move the project foward, eventually making HolyC possible outside TempleOS.

Alistair.

Alistair-Bell avatar Jan 19 '21 18:01 Alistair-Bell

Incredible project.

ctrlcctrlv avatar Jun 28 '22 11:06 ctrlcctrlv