Member Avatar for hexstar

Now here's a interesting question I've been pondering but haven't quite been able to solve...how is the first compiler for a platform made (e.g. new OS, processor, etc)?

  • 3 Contributors
  • 7 Replies
  • 180 Views
  • 14 Hours Discussion Span
  • Latest Post Latest Post by alc6379

Dani AI

Generated

Good question, — and good clarifications from and . The practical answer is: the very first compiler for a new platform is created by a deliberate "bootstrap" sequence rather than magically appearing on the target. That sequence mixes small, easy-to-check pieces (an assembler or loader, minimal runtime, an emulator or host tool that emits target binaries) and iteratively grows from a tiny code generator to a full, self-hosting compiler.

A typical bootstrap workflow looks like this:

  1. Provide the basics: a way to produce runnable target binaries (simple assembler or a small binary emitter and a loader).
  2. Create minimal startup/runtime (crt0) and a tiny C runtime or syscall shim so simple programs can run.
  3. Write a tiny first-stage compiler (or code generator) that emits target assembly; compile that compiler on the host to produce target binaries. Run those on the target or in an emulator.
  4. Use the tiny compiler to build a better compiler (retargeted GCC/LLVM front end or a more complete compiler). Repeat until the compiler can build itself natively (self-hosting).
  5. Once native, rebuild toolchain and standard libraries on the target to lock in ABI and runtime behavior.

Practical tips and gotchas: start with an emulator if hardware is scarce — iteration is much faster. Pay attention to ABI, calling conventions, endianness, and object-file format (startup failures often come from mismatched entry points or section layout). Test with tiny programs first: raw register operations, a simple function call, then I/O. Use tools like an object dumper and a disassembler to verify emitted code. If you want to shortcut work, target a retargetable backend (GCC or LLVM) so you only write a backend and a libc/CRT layer instead of a whole frontend.

Recommended Answers

All 7 Replies

Member Avatar for Narue

It's usually just a port of an existing compiler to the new system. It's possible to compile code on one machine for another, you know. That's called cross-compiling.

Member Avatar for hexstar

huh? how is it possible to compile something for say, PPC on a Intel platform?

Member Avatar for alc6379

It just "is"-- all compiling is is translating the higher level code to machine language. That, at heart, is just translation. Any machine can do that.

Member Avatar for hexstar

That's true but last I checked the machine code for Intel and PPC platforms are different, as an example, one can't run linux apps compiled on a Intel computer and one can't run a linux app compiled on a PPC computer (a mac), as far as I know in order for a application to work on a certain processor it has to be compiled on that processor...of course there's obviously something you guys are trying to tell me that I'm just missing...hmmm...

Member Avatar for alc6379

I think you've got your terminology mixed up. There's compiled on and compiled for. I can have code that's compiled on an AMD64 machine, but it's for a PPC machine.

Like I was mentioning earlier, it's just a matter of knowing how to translate the source code into the machine code that the target processor can read. The translation is a task that any machine can do, because it's just processing one form of input into another form of output. That's what computers do by nature.

Case in point: I've got an old Sparcstation with a 60mhz processor. If I need to compile something for it, rather than wait an hour for something to finish, I can compile it on my Athlon XP system in a fraction of the time. That's because I have appropriate cross-compilers for that platform.

Without getting into the specifics of machine-specific instruction code, the important thing to keep in mind is that one machine can compile code for another system quite easily, because all it compiling is, essentially, is taking one type of input (source code) and outputting it in another form (machine-specific code). There's logic applied to optimize the machine code, but even still, all we're doing is taking an input and translating it to a desired output format.

Member Avatar for hexstar

Ah yeah that's true I suppose, just haven't come by any programs that do that as far as I know, thanks for your replies :)

Member Avatar for alc6379

Ah yeah that's true I suppose, just haven't come by any programs that do that as far as I know, thanks for your replies :)

Glad to help-- if you're really interested in checking out cross-compiling in action, check out NetBSD. They wouldn't have been able to compile everything that they do if not for cross compiling-- it's simply not feasible to compile an entire native OS on and for an Amiga with a 40mhz 68040 processor, when you could do it on a dual Opteron system!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.