Screw that lets compile like it's 1981, when I started. Actually, no thank you.
Let's compile like it's 1992 (2014)
51–60 of 84 posts
Re: Let's compile like it's 1992 (2014)
#52Wow, that Borland IDE UI certainly brings back memories. Turbo Pascal 6.0 (for DOS) was my first real exposure to programming (not counting the various BASICs and a short stint learning 6502 assembly) and led to my teenage self writing a bunch of "IGMs" for Legend of the Red Dragon [0], a BBS game. Unfortunately, just as I started teaching myself C, I scored a copy of Visual Basic 3.0 and it was all downhill from the…
The language/IDE of choice at college was Turbo Pascal. But then they introduced Turbo C and I just had to use it for my graphics class (because C was obviously going to be faster than that Pascal stuff, right?)
Wrong. The Pascal compiler had had years of optimization done to it and their C compiler was a 1.0 product. My programs ran at half the speed of everyone else's.
Re: Let's compile like it's 1992 (2014)
#53No mention of how much time it took to compile? I don't know if my memory is faulty but I remember Turbo C++ to be much much faster than today's C++ compilers.
Many fast compilers of that period left partially compiled files on disk so that generating the final target could be faster. Also, the analysis they performed for optimisation was much simpler than what we do these days (as processors of the time didn't have much to optimise for).
Re: Let's compile like it's 1992 (2014)
#54No mention of how much time it took to compile? I don't know if my memory is faulty but I remember Turbo C++ to be much much faster than today's C++ compilers.
I don't know about c++, but turbo pascal compiled so fast that it felt like an interpreter back in the day.
Pretty close. Back in high school, I was the 'Pascal guy' and one of my friends was the 'C guy.' One day, the friend, after looking through the large list of compiler and linker optimizations available in Borland C++ (and confirming they weren't in my Turbo Pascal) said we should have a Hello World file size competition--see who could get the smallest filesize with our respective languages (compilers really). He spent half a class period digging through the options, reading what would be best, then typed his Hello World program, and announced he was ready. Literally while his code was compiling (these were 386 machines IIRC which took some seconds back in the day), I typed the one-liner and built my code with Turbo Pascal...before his compilation was done.
I had no idea if my executable would be bigger or smaller than his, but I didn't want to put effort into the contest until I knew I was behind. As it turns out, it was about half the size of the C executable and he never asked for a round two. My friend was very frustrated that day.
Fun day.
EDIT: I did some research. They were actually at best 286 machines. The computer lab had those IBM PS/2 all-in-ones with MCGA graphics.
Re: Let's compile like it's 1992 (2014)
#55Earlier quoted context omitted.
tcc is blazingly fast, at least last time i used it. it's honestly fast enough that you could probably use it as an c interpreter
Any technical reasons in particular? I'm curious. How many passes is it doing? I suspect they aren't doing much optimization then? Maybe they patch in differences in the ASTs at the IR level and work from there?
My understanding is TCC does little to no optimization; it's intended to be used for bootstrapping.
Re: Let's compile like it's 1992 (2014)
#56I did this with the original xdoom source when I was a teenager. It all basically works w/ some minor changes. The biggest hurdle is setting up X w/ some goofy color depth.
Re: Let's compile like it's 1992 (2014)
#57There was something about the visceral nature of the tc environment and editor and toolset that just felt like you were very mentally close to the code you were writing. Perhaps something about the bare simplicity. I can't help but feel i've been chasing it ever since in emacs.
Recently I had to do something I always avoided since it was platform specific a huge unknown space to me - code something in C#. It was one of the most pleasurable experiences with "programming" since those Pascal times, and gave that feeling of being close to the code. I attribute it to fast compiles, no need for context switching (due to superb autocompletion), and everything just working well inside the tool. Doc…
Edit and continue is the best thing about C#, its so useful to be able to set a breakpoint, and modify code in debug mode, move back a few lines and try again.
Re: Let's compile like it's 1992 (2014)
#58Earlier quoted context omitted.
tcc is blazingly fast, at least last time i used it. it's honestly fast enough that you could probably use it as an c interpreter
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.
Re: Let's compile like it's 1992 (2014)
#59Earlier quoted context omitted.
That is an understatement. That is a full build of my 3D engine - http://i.imgur.com/3ApRyuQ.png (C not C++ but the linked article is also about a C codebase) on my current computer (4770K i7) under Borland C++ 5.0. Partial builds (modify a file and run) are instant, which is basically why i'm using it for a lot of my C code (the code also compiles in other compilers, like OpenWatcom, GCC, Clang, Visual Studio, Digit…
> 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…
The command line compiler was a separate compiler for when you wanted to use some external method for building (like a batch file) or your program was very big to compile with the IDE in memory (remember this was real mode with a 640K RAM limit, often less than that was available).
But you could take TURBO.EXE (ide+compiler+debugger) and TURBO.TPL (the library), put it on a floppy and work from there. Back when i was a kid, my process to start a new "project" was to take a blank floppy and copy those files (and a couple of units i was sharing) since i didn't have a hard disk. I still have a ton of floppies littered with turbo.exe/tpl pairs.
The Turbo C/C++ also needed only a single executable, tc.exe/bc.exe (depends on the version) and the include and lib directories.
This is the same with Borland C++ 5.0 i am talking about above, although that one also needs a bunch of DLLs too. Since i don't want to break my installation, i only renamed the bcc32.exe and bcc32i.exe to something else, run the IDE and built my engine. As i expected it worked. Although the fact that you can make modifications and have them compiled without saving the file is also an indicator.
Re: Let's compile like it's 1992 (2014)
#60Earlier 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…
You are correct. You could fire off a build from inside the IDE or from the command line itself. I remember it quite well.
That was a separate compiler. It would be as if someone took libtcc and made an IDE use it directly but also bundled the tcc binary for command-line builds.