Live data from Hacker News

A minimal C compiler in x86 assembly

github.com

61–70 of 79 posts

Re: A minimal C compiler in x86 assembly

#61
post #49
post #25

Earlier quoted context omitted.

The link https://github.com/oriansj/talk-notes/blob/master/DECISIONS.... I think that the takeaway is familiarity trumps technical 'superiority'. That said I don't know why having a working GC for Lisp is that important because typically you'd use Lisp to compile your C-compiler so memory efficiency doesn't really matter..

> I think that the takeaway is familiarity trumps technical 'superiority'. No, that's not what's stated in the wiki. The section on Forth points out the lack of useful programs actually written in Forth (a nudge to how no one bothers with the language as alternatives are always found to be preferable), and the lack of developers available to help with the work. The section on Lisp states quite clearly that "LISP is n…

> LISP is not an easy language to implement in LISP, C and definitely not an easy task to implement in assembly

I can't speak to the ease of implementing Lisp in assembly, but I found it easy to do in C. It's trivial to implement Lisp in Lisp if you're willing to let the hosting Lisp do the heavy lifting. The person who I'm quoting isn't a very clear writer though, and his usage of "LISP" suggests he's not exactly up to date on the state of Lisp, so perhaps I'm missing some unstated context that makes his statement sensible.

While I do find the "put up or shut up" message entertaining, it's a category error to confuse what has been done with what can be done. Still, I would consider it a win if some Lisper rises to the challenge.

Since the C language and modern CPUs basically co-evolved, it's not surprising that they're a good fit for each other. The story might be different on a Symbolics machine.

Re: A minimal C compiler in x86 assembly

#62
post #58

Earlier quoted context omitted.

GCC 11 and newer requires a C++11 compiler, 4.8 was the first to require C++ at all, and I think that there are some very old versions of GCC that can be built with a pre-standard C compiler.

"just compiling" gcc means to have all its SDKs dependencies satisfied too... g++ 4.7.4 is the last g++ written in simple C. In theory, you should be able to compile all gccs above 4.7.4 (with their SDKs) with g++ 4.7.4 (Last time I tried I was successful with a gcc10 for x86). I wonder who are the "geniuses" who pushed the gcc steering committee to move gcc to C++98 (the pedophile Epstein?). That said, the C based d…

Terry A. Davis? I thought you got hit by a train?

Re: A minimal C compiler in x86 assembly

#63
post #60

Trusting trust all the way down: How do you trust your assembler to output the exact machine code corresponding to the source? How do you trust whatever program you might use to do the validation? Ok, let's skip the assembler and write machine code directly. How do you trust the program you use to write that machine code? How do you even trust the firmware will execute your machine code in the way you intend?

You break out the handy old electron microscope and check that the bits written are what you expect.

Your joke is funny, but it's also not a complete joke. I worked at a company that was running out of funds shortly after firing me, well I kind of fired myself, but I was gone. They had a beautiful electron microscope, and figured why don't we pivot to something involving chips?

Re: A minimal C compiler in x86 assembly

#64
post #57

Earlier quoted context omitted.

You can't control when an apocalypse happens, so you might as well just not prepare for it. That's essentially the same argument, which is ridiculous. Of course you can. And you should. Just because you can't control the entirety of a system, doesn't mean you can't take steps to minimize risks and exposure, and shrink the attack surface.

That is a stupid analogy. I'm talking about a machine. You are not in control unless you build the machine yourself. Even if you were provided schematics, you cannot be sure they are accurate. The point is free software does not minimize risk. It's a false sense of security. For things you actually care about, such a surveillance, what if I told you there is a hardware backdoor in your CPU allowing the government to…

I built a CPU myself out of 74xx logic, but I can't be sure that every input on every chip isn't also connected internally to an integrated computer that stores everything it sees and can transmit it to a van at 20 metres range (easily enough for someone to drive up to my house and retrieve the contents periodically).

The attacker can then reconstruct everything that happened on the CPU and work out what I've been up to. Or, more likely, throw away almost everything and only look at what was printed to the console, because everything interesting goes to the console anyway.

In fact this would be easier-than-average to achieve because the clock speed is low, I don't run the machine for very long or very often, and the density of actual electronics to "free space" on the ICs is very low (more space for shenanigans), and all my schematics are on my github project so even though you don't know which chip is connected to which other, you shouldn't have too much trouble deriving it.

So what now? Do we just give up? Is all computing fundamentally impossible? Or do we accept that nothing is perfect and just get on with it?

Re: A minimal C compiler in x86 assembly

#65
post #17

While everyone asks about lisp or forth for this task, I have to wonder what one has to leave out of C to make it "minimal" enough for this task. The subset of features left out might teach us something about the language.

It's not exactly the things you have to leave out of C. It's that for a compiler bootstraper, C gives you extremely little bang for your buck.

If you in the lisp route, you'll soon be talking about embedding a grammar DSL or a validator. On C, you will be happy to create a parser and please, let's get to the next project already.

Re: A minimal C compiler in x86 assembly

#66
post #59

Earlier quoted context omitted.

You would need to compile the newer versions with the older versions. The first C++ compiler was probably written in C.

Interestingly enough, Cfront[1] was written in C++. [1] https://en.wikipedia.org/wiki/Cfront

A trope of old-school compiler development is, "We made our language self-hosting, and then we compiled it by hand."

Re: A minimal C compiler in x86 assembly

#67
post #57

Earlier quoted context omitted.

You can't control when an apocalypse happens, so you might as well just not prepare for it. That's essentially the same argument, which is ridiculous. Of course you can. And you should. Just because you can't control the entirety of a system, doesn't mean you can't take steps to minimize risks and exposure, and shrink the attack surface.

That is a stupid analogy. I'm talking about a machine. You are not in control unless you build the machine yourself. Even if you were provided schematics, you cannot be sure they are accurate. The point is free software does not minimize risk. It's a false sense of security. For things you actually care about, such a surveillance, what if I told you there is a hardware backdoor in your CPU allowing the government to…

You are not smart enough to understand his analogy.

The point is, only my point is valid and anybody that cannot see that is stupid.

There, I think replicated the level of snark and useful discourse fairly well.

Re: A minimal C compiler in x86 assembly

#69
post #61
post #49

Earlier quoted context omitted.

> I think that the takeaway is familiarity trumps technical 'superiority'. No, that's not what's stated in the wiki. The section on Forth points out the lack of useful programs actually written in Forth (a nudge to how no one bothers with the language as alternatives are always found to be preferable), and the lack of developers available to help with the work. The section on Lisp states quite clearly that "LISP is n…

> LISP is not an easy language to implement in LISP, C and definitely not an easy task to implement in assembly I can't speak to the ease of implementing Lisp in assembly, but I found it easy to do in C. It's trivial to implement Lisp in Lisp if you're willing to let the hosting Lisp do the heavy lifting. The person who I'm quoting isn't a very clear writer though, and his usage of "LISP" suggests he's not exactly up…

> While I do find the "put up or shut up" message entertaining, it's a category error to confuse what has been done with what can be done. Still, I would consider it a win if some Lisper rises to the challenge.

The whole point is that there are an awful lot of talkers talking a big game but no none of them ever manages to actually show something working.

The challenge was presented.

Re: A minimal C compiler in x86 assembly

#70
post #36

Trusting trust all the way down: How do you trust your assembler to output the exact machine code corresponding to the source? How do you trust whatever program you might use to do the validation? Ok, let's skip the assembler and write machine code directly. How do you trust the program you use to write that machine code? How do you even trust the firmware will execute your machine code in the way you intend?

In all fairness, we shouldn’t be trusting ourselves, even. (Not always, anyway.)

"Sometimes I'm so sneaky, I don't even trust myself", - Dick Dastardly
Post reply on HN