Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: My C compiler compiled itself

github.com

Post reply on HN
Print view View original

91–100 of 130 posts

Re: Show HN: My C compiler compiled itself

#91

Post by wqweto »

williamdclt wrote: post #78
dbcurtis wrote: post #13

Earlier quoted context omitted.

> Also, I'm curious - did you find yourself having to constrain your use of C in order to make sure that the compiler could compile itself? Or does it implement everything you would use naturally anyways? That would be the "bootstrapping" process. Nearly a half-century ago I took a compiler lab class where we were given a working, but slightly lame, compiler, and were tasked with adding new, less lame, language featu…

I guess the full bootstrapping process would start with writing a basic compiler in assembly?

Usually it’s easier to just cross-compile for the new target. No need to start from ground zero.

Re: Show HN: My C compiler compiled itself

#93

Post by actionfromafar »

mizzao wrote: post #92

Out of curiosity: would ./30cc_gcc (30cc complied by gcc-hosted 30cc) and ./30cc (30cc complied by self-hosted 30cc) be identical binary files, if 30cc was operating as expected?

No, gcc optimizes code output and can make code shorter and faster. A compiler can make many, many decisions which will show up as differences in the binary output.

Re: Show HN: My C compiler compiled itself

#94

Post by cschep »

unwind wrote: post #65
gizmo wrote: post #57

Earlier quoted context omitted.

This kind of condescending advice doesn't help anybody. Redundant casts, like redundant braces, white space, and a plethora of similar choices are stylistic more than anything else. If you really feel the need to give unsolicited coding style feedback maybe at least spend more than a few seconds looking at the code before you do so. Otherwise it's just rude.

Really? Wow. I had no idea, and I really tried to sound non-condescending. I simply don't agree that redundant casts are something to be ignored, since they can be harmful and hide actual errors (the cast is a bit like `sudo make me a sandwich`, it makes the compiler do what you say which is not always a good idea). I guess I believe that publicly posting code, and even writing a compiler for the language in question…

I enjoyed reading the feedback, and their response, and felt no negativity whatsoever. Keep honestly interacting it's good for everyone!

Re: Show HN: My C compiler compiled itself

#95

Post by KerrAvon »

keyvank wrote: post #55
unwind wrote: post #54

Very cool, congratulations! I took a 2-second peek at the code, and just wanted to offer a small piece of advice that I think makes it better. Or two, really. Counting is hard. Instead of (this is from parser.c): apply_result *ret = (apply_result*)malloc(sizeof(apply_result)); apply the two common principles of DRY [1] and "don't cast the return value of malloc()" [2] and you get: apply_result *ret = malloc(sizeof *r…

thanks man! yes that makes sense. unfortunately 30cc is not able to compile that syntax, and will probably give type-checker errors when passing a void* to pointer of another type. but will implement it sometime soon!

I disagree with that advice, FWIW -- (void *) is the cause of a lot of bugs in C programs, and much stricter type checking was often the norm for compilers like CodeWarrior on platforms like classic Mac OS, where (a) if you got something wrong you'd corrupt app memory at best and the filesystem at worst and (b) many developers were used to Pascal, which was stricter. (Moving to GCC on Mac OS X and unexpectedly getting much more lenient type checking was a big surprise.)

Re: Show HN: My C compiler compiled itself

#96

Post by KerrAvon »

keyvank wrote: post #55
unwind wrote: post #54

Very cool, congratulations! I took a 2-second peek at the code, and just wanted to offer a small piece of advice that I think makes it better. Or two, really. Counting is hard. Instead of (this is from parser.c): apply_result *ret = (apply_result*)malloc(sizeof(apply_result)); apply the two common principles of DRY [1] and "don't cast the return value of malloc()" [2] and you get: apply_result *ret = malloc(sizeof *r…

thanks man! yes that makes sense. unfortunately 30cc is not able to compile that syntax, and will probably give type-checker errors when passing a void* to pointer of another type. but will implement it sometime soon!

If you're implementing C23 compatibility, you could do

  auto p = (thing_t *)malloc(sizeof(thing_t));
and you get both DRY and avoid (void *) casting.

Re: Show HN: My C compiler compiled itself

#97

Post by munch117 »

KerrAvon wrote: post #95
keyvank wrote: post #55

Earlier quoted context omitted.

thanks man! yes that makes sense. unfortunately 30cc is not able to compile that syntax, and will probably give type-checker errors when passing a void* to pointer of another type. but will implement it sometime soon!

I disagree with that advice, FWIW -- (void *) is the cause of a lot of bugs in C programs, and much stricter type checking was often the norm for compilers like CodeWarrior on platforms like classic Mac OS, where (a) if you got something wrong you'd corrupt app memory at best and the filesystem at worst and (b) many developers were used to Pascal, which was stricter. (Moving to GCC on Mac OS X and unexpectedly gettin…

But adding the cast doesn't make type checking stricter, quite the opposite - it destroys any hope of the compiler checking the assignment.

C++ shot itself in the foot by removing automatic conversion from void* to T*, because it forces programmers to add casts that weaken type safety.

Re: Show HN: My C compiler compiled itself

#98

Post by tetha »

gizmo wrote: post #57
unwind wrote: post #54

Very cool, congratulations! I took a 2-second peek at the code, and just wanted to offer a small piece of advice that I think makes it better. Or two, really. Counting is hard. Instead of (this is from parser.c): apply_result *ret = (apply_result*)malloc(sizeof(apply_result)); apply the two common principles of DRY [1] and "don't cast the return value of malloc()" [2] and you get: apply_result *ret = malloc(sizeof *r…

This kind of condescending advice doesn't help anybody. Redundant casts, like redundant braces, white space, and a plethora of similar choices are stylistic more than anything else. If you really feel the need to give unsolicited coding style feedback maybe at least spend more than a few seconds looking at the code before you do so. Otherwise it's just rude.

> If you really feel the need to give unsolicited coding style feedback maybe at least spend more than a few seconds looking at the code before you do so. Otherwise it's just rude.

Mh, at the same time, people who know their craft can give solid feedback within a very short timeframe. It's very impressive how good sound engineers can just pickup your mixed recording, listen to some 5 second batches, 15 - 20 seconds in total and already give very solid advice for improvement. Or when I was playing foosball more actively with league players. I could hold myself, but after 2-3 exchanges they could usually point out some technique issues.

I found GPs feedback (and the resulting discussion, heh) useful and the resulting code cleaner (in case I ever have to touch C-Code again, brr), and then learned that the compiler can't do that yet.

Re: Show HN: My C compiler compiled itself

#99

Post by unclad5968 »

yodsanklai wrote: post #64
unclad5968 wrote: post #23

Earlier quoted context omitted.

As someone that learned C# and python before C and C++, to this day I couldn't explain to you how make rules work. Make is so unlike build tools from other languages that it doesn't surprise me someone would rather use python to bootstrap their compiler.

> Make is so unlike build tools from other languages Interesting, I thought that "make" was like multiplication tables, something you learn very early one as it's a super simple tool. Also I assumed it was part of any unix 101 class, together with bash and command line stuff. But probably it shows my age. Most people don't have any reason to learn these tools nowadays.

That is likely the case for anyone formally educated in C. If I needed to learn make I would, but I use cmake because I develop on multiple platforms.
Post reply on HN