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

A minimal C compiler in x86 assembly

github.com

Post reply on HN
Print view View original

41–50 of 79 posts

Re: A minimal C compiler in x86 assembly

#41

Post by kragen »

d33 wrote: post #37
kragen wrote: post #32

Earlier quoted context omitted.

How do you detect a backdoor inserted in the login program with a test? You'd have to know the backdoor password to write the test. Perhaps you haven't read Thompson's Turing Award lecture and so you have no idea what we're talking about.

Not sure if it would work, but wouldn't it greatly complicate creating a backdoor when the host's memory is very heavily constrainted? e.g. an AVR-based "computer" that would hardly do much more than actually translate assembly to machine code?

It would probably be easier to detect, but when Thompson deployed the attack in practice, nobody noticed, even though the PDP-11 address space was the same size as an AVR's, and the CPU was a lot slower. (AVRs invariably have much less physical RAM installed than a PDP-11, but you'd need some external memory to get a C compiler to build.)

Re: A minimal C compiler in x86 assembly

#42

Post by pflanze »

It appears that this project is in competition with Mes[1], which is also running under the http://bootstrappable.org/ 'umbrella', and which implements both a Scheme interpreter (in C) and a C compiler (in Scheme) it is designed to run.

The C compiler that Mes was written for, MesCC, appears to be using some 600 lines of code excluding libraries, which I haven't checked how large they are. It might be smaller than cc_x86.s[2] posted here (or it might not when including the libs), but if concerned about bootstrapping size, the size of the Scheme interpreter would have to be included as well and then the size is surely larger than cc_x86.s; also, I'm unclear about how Mes solves the mutual dependency issue of Scheme C.

Mes is authored primarily by Jan (janneke) Nieuwenhuizen. Judging from a comment by Janneke on IRC[3] collaboration seems amicable, if I'm not mis-attributing this quote:

    some routes we try just are a dead end...
Not having any ties to either project I welcome corrections of any mistakes I may have made here.

[1] https://www.gnu.org/software/mes/ [2] https://github.com/oriansj/stage0/blob/master/stage2/cc_x86.... [3] http://logs.guix.gnu.org/bootstrappable/2022-05-01.log

Re: A minimal C compiler in x86 assembly

#43

Post by samhw »

ducktective wrote: post #7
pabs3 wrote: post #6

Earlier quoted context omitted.

A recent comment from LWN on that note: https://lwn.net/Articles/893608/ I asked about this on their IRC channel and got this response from oriansj: Well we did bootstrap a FORTH from hex: https://github.com/oriansj/stage0/blob/master/stage2/forth.s and we did bootstrap a garbage collecting Lisp from hex: https://github.com/oriansj/stage0/blob/master/stage2/lisp.s but if you notice: https://github.com/oriansj/stage0/…

I miss these technical provocative challenges. Nowadays, everyone tries to "not offend" people.

'Nowadays' as opposed to ... 7 hours ago?

Re: A minimal C compiler in x86 assembly

#44

Post by Flankk »

jstanley wrote: post #39
Flankk wrote: post #38

Earlier quoted context omitted.

This is what I don't understand about Stallman. Even if we all agree to use free software, that's only the beginning. The next step is nobody is going to use web applications anymore. Okay now that we're all liberated from corporate espionage what about how the software is made. You can't trust package maintainers any more than you can trust companies. So we all use GNU/Gentoo. As you said, the compiler may be compro…

This is just a long-winded way of saying "if you can't solve everything, don't solve anything", which is no way to approach problems.

No, you've missed the point. Don't you understand? The software cannot be trusted whatsoever unless you control the entire stack. So you haven't solved anything. Also, if you think a paragraph is long winded then I'm sure you have never listened to Stallman.

Re: A minimal C compiler in x86 assembly

#45

Post by janneke »

pflanze wrote: post #42

It appears that this project is in competition with Mes[1], which is also running under the http://bootstrappable.org/ 'umbrella', and which implements both a Scheme interpreter (in C) and a C compiler (in Scheme) it is designed to run. The C compiler that Mes was written for, MesCC, appears to be using some 600 lines of code excluding libraries, which I haven't checked how large they are. It might be smaller than cc…

Ah no, there is no competition, at least not yet ;)

Stage0---of with cc_x86.c is a part---as a project started off from the bottom (hex0) and is working up. When stage0 just started, I created GNU Mes soon to be folowed by MesCC, which aimed to build a version of TinyCC and the remaining bootstrap for GNU Guix. The first versions of mescc had its own linker, which was later in a joint effortt replaced by M1 and hex2 from MesCC-Tools (also part of Stage0.

My initial idea for Mes was to translate it by hand to assembly, so the M1 assembler would come in handy. As it turned out, cc_x86.c and its next step M2-Planet were developed as part of Stage0.

Starting from an 357-byte hex0 provided by the bootstrap-seeds, Stage0-posix builds hex0, kaem, hex1, catm, hex2, M0, cc_x86, M1, M2, get_machine, (mescc-tools), and M2-Planet. M2-Planet in turn builds Mes, which builds a bootstrappable TinyCC, etc.

Re: A minimal C compiler in x86 assembly

#46

Post by userbinator »

x86 Asm of a very different syntax (neither Intel nor AT&T), to be fair. For a second, I thought it was ARM. Then I started to parse some of the syntax and realised it could be made even more minimal, e.g. this function

    ;; in_set function 
    ;; Receives a Char in R0, char* in R1 
    ;; Return result in R0
based on what it seems to do, can almost certainly be replaced with a simple repnz scasb.

Re: A minimal C compiler in x86 assembly

#47

Post by userbinator »

matthews2 wrote: post #31
martincmartin wrote: post #28

Earlier quoted context omitted.

Their goal is to compile GCC, so whatever subset of C GCC uses.

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.

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

Re: A minimal C compiler in x86 assembly

#48

Post by userbinator »

Koshkin wrote: post #36
glandium wrote: post #29

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.)

...and instead, trust the megacorps?

That's how my mental autocomplete goes, and it is a really disturbing train of thought because this is how dystopia starts.

Re: A minimal C compiler in x86 assembly

#49

Post by arinlen »

renox wrote: post #25
arinlen wrote: post #20

Earlier quoted context omitted.

> I'm surprised they wrote a minimal C compiler in assembly rather than any LISP dialects, then make a C compiler in LISP I recommend you check out the author's GitHub page. It includes Forth and Lisp projects, explains why C was a success while those projects failed, and challenges any Forth and Lisp fan to actually substantiate their baseless claims with actual work instead of pushing beliefs that don't have any be…

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 not an easy language to implement in LISP, C and definitely not an easy task to implement in assembly".

Re: A minimal C compiler in x86 assembly

#50

Post by pflanze »

janneke wrote: post #45
pflanze wrote: post #42

It appears that this project is in competition with Mes[1], which is also running under the http://bootstrappable.org/ 'umbrella', and which implements both a Scheme interpreter (in C) and a C compiler (in Scheme) it is designed to run. The C compiler that Mes was written for, MesCC, appears to be using some 600 lines of code excluding libraries, which I haven't checked how large they are. It might be smaller than cc…

Ah no, there is no competition, at least not yet ;) Stage0---of with cc_x86.c is a part---as a project started off from the bottom (hex0) and is working up. When stage0 just started, I created GNU Mes soon to be folowed by MesCC, which aimed to build a version of TinyCC and the remaining bootstrap for GNU Guix. The first versions of mescc had its own linker, which was later in a joint effortt replaced by M1 and hex2…

Thanks for your answer!

I'll try out some bootstrapping paths and will make an effort of getting a full understanding of the whole picture, and am hoping to write something up about what I find out.

(BTW I did ask on IRC, some further details might be found from the answers I got here: http://logs.guix.gnu.org/bootstrappable/2022-05-03.log#14495...)

Post reply on HN