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

Let's compile like it's 1992 (2014)

fabiensanglard.net

Post reply on HN
Print view View original

71–80 of 84 posts

Re: Let's compile like it's 1992 (2014)

#71

Post by buserror »

juliangoldsmith wrote: post #58
buserror wrote: post #34

Earlier quoted context omitted.

I do use it as interpreter on embedded boards! Preprocess/trim the headers you need, and add #!/bin/tcc -run at the top of your .C file, add a +x to it and it'll run just fine! I love tcc, in fact I added a firmware instruction translator to 'JIT' AVR code to simavr a few weeks ago. Takes a AVR binary, translates it to C, and compiles it on the fly with libtcc to run it :-) https://github.com/buserror/simavr/tree/jit…

>I love tcc, in fact I added a firmware instruction translator to 'JIT' AVR code to simavr a few weeks ago. Takes a AVR binary, translates it to C, and compiles it on the fly with libtcc to run it :-) That is unholy, and glorious.

Ahah, thanks for that -- I thought it was pretty clever, but it's hard to explain why to someone :-)

If you look closer, you can see I've actually repurposed the main interpreter core, and uses a GNU awk (of all thing) to extract each opcode emulation 'meat', converts it to a string to and that string is used by the translator to generate the C for tcc...

Re: Let's compile like it's 1992 (2014)

#72

Post by jklowden »

bluedino wrote: post #66
laumars wrote: post #42

Earlier quoted context omitted.

> The compiler is part of the IDE, not some external process that needs to start from a blank state for each file I'm pretty sure Borland used to separate out the IDE executables from the compilers and a couple of other tools tool. I don't have a copy to hand to prove this but I'm sure I used to occasionally invoke Turbo Pascal's compiler from the command line outside of the IDE (due to it being a separate .exe / .co…

>> I'm pretty sure Borland used to separate out the IDE executables from the compilers Turbo C was like that, but not the first few versions of Turbo Pascal. The whole goal with Turbo Pascal was to have everything in one small program so you could code/compile/test as fast as possible. It used a one-pass compiler and didn't have a heavy linker. It was fast even on a 8088. Anders Hejlsberg was the original author of T…

Remember, Wirth designed Pascal as a teaching language. One-pass compilation, no forward declarations, built-in I/O. Turbo Pascal could compile to a .com file, 64KB max, 16-bit pointers. I'm not sure there was a linker; the first executable instruction was the first byte in e file.

The neat trick was debugging. Instead of tagging to object code with source-code line numbers, to break on line N, Turbo Pascal simply recompiled the source up to line N, and used the size of the output to match the instruction pointer in the debugged image. Move to next line? Compile one more line, and stop at the last produced instruction.

But these were tiny programs, written ab initio. No readline, no X, no network, no database. Hardly any filesystem. To do something akin to readdir(3) meant writing a bespoke function to call the DOS interrupt. Putting a menu on the screen required positioning the cursor in the video buffer and putting each character in successive locations, allowing for the attribute byte.

If Turbo Pascal was simple, it was also primitive. Much bigger C programs compile in the blink of an eye today. Complex programs take a long time to build today, yes. They did then, too.

Re: Let's compile like it's 1992 (2014)

#73

Post by RugnirViking »

kibwen wrote: post #3

Let's play the game "Wolfenstein miscompilation or Dwarf Fortress screenshot?": http://fabiensanglard.net/Compile_Like_Its_1992/images/run_w...

It took me a while of thinking 'Isn't it obvious that it's not dwarf fortress?' before realizing that I am way too into that game to be the intended audience for the joke ;)
Post reply on HN