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

Let's make a Teeny Tiny compiler

austinhenley.com

Post reply on HN
Print view View original

21–30 of 39 posts

Re: Let's make a Teeny Tiny compiler

#21

Post by catwind7 »

kerkeslager wrote: post #13
azhenley wrote: post #7

Earlier quoted context omitted.

Part 3 is the emitter that produces C: https://web.eecs.utk.edu/~azh/blog/teenytinycompiler3.html

Ah, okay. It looks like you're taking a fairly C-like language and transforming it to C--I'd call this a transpiler rather than a compiler. You're not wrong to call it a compiler, but it's a pretty noncentral example of a compiler. Congrats on at least having an emitter, but I'm still searching for an article that shows how to emit assembly of any kind.

nand2tetris is a great course that shows you how to design a computer from the chip level, build an assembler, and write a high level language + compiler that eventually produces the assembly code for the machine architecture _you_ built. I highly recommend it.

Re: Let's make a Teeny Tiny compiler

#23

Post by jermaustin1 »

kerkeslager wrote: post #15
zachrip wrote: post #11

Earlier quoted context omitted.

I'll take "what is due diligence" for 300, Alex.

I guess I was technically wrong in that it does have an emitter, but I wasn't wrong in that it still doesn't emit assembly. gcc (or whatever you're using to compile your C) is still doing all the nuclear reactor part.

I believe what you are meaning by assembly is native code or the executable bytes that a compiler/linker/assembler output?

Assembly is just another language (or more precisely: family of languages).

Re: Let's make a Teeny Tiny compiler

#24

Post by dang »

azhenley wrote: post #22
dang wrote: post #17

https://news.ycombinator.com/item?id=23441767

That was before it was completed :(

That's one problem with these multipart blog posts. It becomes ambiguous whether the submission is "part 1" or the head of the list ("part 1" "part 2" "part 3").

If you want to make a single long version of the page that includes all three parts, I'd be happy to arrange a repost. It would be best to email hn@ycombinator.com about it.

Re: Let's make a Teeny Tiny compiler

#25

Post by catwind7 »

jermaustin1 wrote: post #20
kerkeslager wrote: post #13

Earlier quoted context omitted.

Ah, okay. It looks like you're taking a fairly C-like language and transforming it to C--I'd call this a transpiler rather than a compiler. You're not wrong to call it a compiler, but it's a pretty noncentral example of a compiler. Congrats on at least having an emitter, but I'm still searching for an article that shows how to emit assembly of any kind.

Instead of outputting c, could you not just output the equivalent assembler? so instead of self.emitter.emitLine("printf(\"" + self.curToken.text + "\\n\");") you do something like self.emitter.emitLine("STRING DB " + self.curToken.text + "', '$'") ... self.emitter.emitLine("LEA DX,STRING") self.emitter.emitLine("MOV AH,09H") self.emitter.emitLine("INT 21H")

there's certainly equivalent assembler, but depending on the architecture you're targeting this can be a pretty monumental task. Even a single function call can be north of a hundred lines or something (i'm making this up :D )

I guess that's why we have things like LLVM that allow you to generate intermediate representations that get converted to a bunch of different instruction sets

Re: Let's make a Teeny Tiny compiler

#26

Post by kerkeslager »

catwind7 wrote: post #14
kerkeslager wrote: post #4

I'm sorry to be negative here, but this article, like most articles about compilers, is bike shedding. For those not aware of the bike shedding metaphor, it's the assertion that when discussing the design of a nuclear power plant, everyone will want to discuss the color of the shed where the workers store their bikes because they understand it. Meanwhile, nobody will want to discuss the nuclear reactor itself, becaus…

so what if it is? i know what the bike shedding metaphor is and frankly you're stretching it a bit because all this person is trying to do is educate and they're not even saying this is the only way to do it. seems odd to pull out the bike shed metaphor for every case there's an abundance of technical articles on a subject matter. There's lots of tutorials on for loops in X language. Do you consider that bike sheddin…

I'm not gonna argue with you over whether the metaphor I used was applicable or not--the point of the metaphor was to communicate and it's clear I succeeded in communicating. It's clear you understood what I meant, because you provided another example. Yes, whether or not you agree the bike shedding metaphor applies, you have to agree that having the 100th tutorial on how to do something that's in the docs that ships with the language is equally pointless.

Re: Let's make a Teeny Tiny compiler

#27

Post by jermaustin1 »

catwind7 wrote: post #25
jermaustin1 wrote: post #20

Earlier quoted context omitted.

Instead of outputting c, could you not just output the equivalent assembler? so instead of self.emitter.emitLine("printf(\"" + self.curToken.text + "\\n\");") you do something like self.emitter.emitLine("STRING DB " + self.curToken.text + "', '$'") ... self.emitter.emitLine("LEA DX,STRING") self.emitter.emitLine("MOV AH,09H") self.emitter.emitLine("INT 21H")

there's certainly equivalent assembler, but depending on the architecture you're targeting this can be a pretty monumental task. Even a single function call can be north of a hundred lines or something (i'm making this up :D ) I guess that's why we have things like LLVM that allow you to generate intermediate representations that get converted to a bunch of different instruction sets

For sure, i'm just telling the GP that their request for something that outputs assembly could be done with minor modifications depending on the assembly language they want to output.

Re: Let's make a Teeny Tiny compiler

#28

Post by kerkeslager »

dlo wrote: post #16
kerkeslager wrote: post #13

Earlier quoted context omitted.

Ah, okay. It looks like you're taking a fairly C-like language and transforming it to C--I'd call this a transpiler rather than a compiler. You're not wrong to call it a compiler, but it's a pretty noncentral example of a compiler. Congrats on at least having an emitter, but I'm still searching for an article that shows how to emit assembly of any kind.

I used to work on a static analyzer that did taint analysis, model checking, buffer bounds checking, and so on -- a bit like a compiler backend on steroids. If there's a specific topic you'd like an explanation on, I could be convinced to write something up. My favorite was always context-sensitive, interprocedural points-to analysis. And dataflow analysis in the presence of higher-order controlflow constructs.

Honestly, I'd just like to see anything that outputs assembly I can run through an assembler to create an executable. I've fumblingly written a bit of this code myself, but always felt hampered by a lack of knowledge.

Re: Let's make a Teeny Tiny compiler

#29

Post by kerkeslager »

jermaustin1 wrote: post #20
kerkeslager wrote: post #13

Earlier quoted context omitted.

Ah, okay. It looks like you're taking a fairly C-like language and transforming it to C--I'd call this a transpiler rather than a compiler. You're not wrong to call it a compiler, but it's a pretty noncentral example of a compiler. Congrats on at least having an emitter, but I'm still searching for an article that shows how to emit assembly of any kind.

Instead of outputting c, could you not just output the equivalent assembler? so instead of self.emitter.emitLine("printf(\"" + self.curToken.text + "\\n\");") you do something like self.emitter.emitLine("STRING DB " + self.curToken.text + "', '$'") ... self.emitter.emitLine("LEA DX,STRING") self.emitter.emitLine("MOV AH,09H") self.emitter.emitLine("INT 21H")

Well, what you just posted already highlights one difficulty: when you come to the PRINT statement, you have to emit the string and the instructions to two different places, so we're already talking about having two different emitters, or some other way of handling this. And we need to generate different non-conflicting names/addresses depending on architecture.

You said in your other post that this can be done with minor modifications, but I can already foresee a few modifications that would need to be made which aren't minor.

And then there's the problem that you may want to target more than one architecture. We can write two completely different code generators, but it would be nice if there were an architecture that could share some of the code.

Re: Let's make a Teeny Tiny compiler

#30

Post by catwind7 »

kerkeslager wrote: post #26
catwind7 wrote: post #14

Earlier quoted context omitted.

so what if it is? i know what the bike shedding metaphor is and frankly you're stretching it a bit because all this person is trying to do is educate and they're not even saying this is the only way to do it. seems odd to pull out the bike shed metaphor for every case there's an abundance of technical articles on a subject matter. There's lots of tutorials on for loops in X language. Do you consider that bike sheddin…

I'm not gonna argue with you over whether the metaphor I used was applicable or not--the point of the metaphor was to communicate and it's clear I succeeded in communicating. It's clear you understood what I meant, because you provided another example. Yes, whether or not you agree the bike shedding metaphor applies, you have to agree that having the 100th tutorial on how to do something that's in the docs that ships…

i think you succeeded in communicating your thoughts and feelings in spite of the metaphor.

there are plenty of documentation in the form of tutorials on for nearly every aspect of every programming language I can think of. I think it's important to keep in mind that we all learn differently and sometimes one explanation can make no sense while another makes a lot of sense.

That said, I think I get your frustration in that sometimes the process of _finding_ the explanation that clicks for whatever your question is (how to emit assembler?) can be really painful because all the explanations are shallow.

However, I don't think it's fair to take that frustration out on the writers (I got the impression you were, but maybe you weren't and just felt like venting). I for one encourage engineers to write if no for no other reason than to better cement their own understanding.

I do wonder, though, if maybe there's some improvements we can make to how we filter / search for long-form technical articles outside of google so that the content is more relevant

Post reply on HN