On Sat, 14 Feb 2009 13:47:20 -0800, Darren New wrote:

> Jim Henderson wrote:
>> That used to be common with GCC
> 
> I remember seeing the bootstrap code for compiling Hermes, which had its
> own assembly language that looked a lot like SQL for example. :-) It had
> comments in there like "Only Greg, the God of Awesome, is allowed to
> touch this, because the rest of you keep screwing it up."

LOL, love it.

The oddest system I ever saw was one that used lisp at the system level.  
I can't for the life of me remember the manufacturer of the system.  It 
was used for a prototype of an ATC simulator where the system applied AI 
to the situation to do the control for the operator - used for training 
purposes.

Jim

Post a reply to this message

Orchid XP v8 wrote:
> I should probably get out more...

Oh, and for some reason I picked this backlogged link to read today, for 
anyone who doesn't know the basics of writing their own compiler.

http://msdn.microsoft.com/en-us/magazine/cc136756.aspx

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message

>> Yah, that's right. First you install a binary version of the compiler.
>> Then you use that to compile a minimal version of the compiler from
>> source. Then you use *that* to compile a full version from source.
> 
> That used to be common with GCC - not sure if that's the one you're 
> using, but I remember the first time I saw it built was on a SunOS 
> platform, used the Sun CC compiler to build the first time and then it 
> built itself in order to fully optimise itself.
> 
> On hardware of the time, it generally took about 12 hours IIRC.

Actually, I'm recompiling the Haskell compiler. Which is written in 
Haskell. (And a small amount of C.)

It's still compiling. o_O

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:

> It's still compiling. o_O

...still going...

It has at least now finished compiling all the libraries. It's now 
recompiling the compiler.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Sat, 14 Feb 2009 22:07:01 +0000, Orchid XP v8 wrote:

>>> Yah, that's right. First you install a binary version of the compiler.
>>> Then you use that to compile a minimal version of the compiler from
>>> source. Then you use *that* to compile a full version from source.
>> 
>> That used to be common with GCC - not sure if that's the one you're
>> using, but I remember the first time I saw it built was on a SunOS
>> platform, used the Sun CC compiler to build the first time and then it
>> built itself in order to fully optimise itself.
>> 
>> On hardware of the time, it generally took about 12 hours IIRC.
> 
> Actually, I'm recompiling the Haskell compiler. Which is written in
> Haskell. (And a small amount of C.)
> 
> It's still compiling. o_O

Interesting....how long has it been running?

Jim

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> >> Yah, that's right. First you install a binary version of the compiler.
> >> Then you use that to compile a minimal version of the compiler from
> >> source. Then you use *that* to compile a full version from source.
> >
> > That used to be common with GCC - not sure if that's the one you're
> > using, but I remember the first time I saw it built was on a SunOS
> > platform, used the Sun CC compiler to build the first time and then it
> > built itself in order to fully optimise itself.
> >
> > On hardware of the time, it generally took about 12 hours IIRC.
>
> Actually, I'm recompiling the Haskell compiler. Which is written in
> Haskell. (And a small amount of C.)

I knew it! ;)

BTW, In my early Debian years I too thought package management sucked.  So, I
began to do my own compilations in a ~/root directory of new packages (gtk and
most of its dependencies) and use those instead with LD_LIBRARY_PATH.
Eventually, I wanted to compile a new version of GCC instead of waiting for the
new version to be packaged to Debian.  All was good, I was learning my way the
hard way.  Then, someday I compiled libc itself and, tired of LD_LIBRARY_PATH,
I decided to replace the current with it.  I don't remember quite exactly what
I did, but I think I *moved* the current libc to /lib/bkup-libc.so or something
and would then move my compiled libc to /lib.  Unfortunately, I couldn't.  The
system began breaking apart, beginning by mv itself and bash and then the whole
system.  Kernel panic ensued eventually.  oh, my...

Nowadays, having learned the hard way in the past, I think package managers are
a blessing.  Not even several /Next/ clicks in a row, just choose what you want
installed and let it go. :)

Post a reply to this message

>> Actually, I'm recompiling the Haskell compiler. Which is written in
>> Haskell. (And a small amount of C.)
>>
>> It's still compiling. o_O
> 
> Interesting....how long has it been running?

In the end, at around about 11:45 PM, I gave up waiting so I could go to 
bed instead. It then took an additional hour or so this morning.

So, in total... hmm... maybe 4 hours? Something of that order.

Remember this is running on a *laptop* that's some 6 years old now. It's 
powered by an AMD Mobile Athlon XP 1400+ CPU. It's not even 64-bit. 
(Mercifully, it *does* have a decent amount of RAM though. I upgraded it 
a while back.)

Anyway, I just made the mistake of running the compiler validation 
script. The first thing this does is... clean the build tree. That is, 
it deletes everything and recompiles from scratch. I guess the idea is 
if you're been working on the compiler all day and you think it should 
work now, it does a full rebuild from scratch to check it really *does* 
work and it's not just that you're using an old result.

Rebuild started at 10:30 AM. We'll see how long it takes to rebuild. :-/

(Of course, as well as compiling the compiler twice, it also compiles 
all sorts of other build tools, the standard libraries twice, builds 
HTML documentation, and sweeps your bedroom floor...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:

> Anyway, I just made the mistake of running the compiler validation 
> script. The first thing this does is... clean the build tree. That is, 
> it deletes everything and recompiles from scratch. I guess the idea is 
> if you're been working on the compiler all day and you think it should 
> work now, it does a full rebuild from scratch to check it really *does* 
> work and it's not just that you're using an old result.
> 
> Rebuild started at 10:30 AM. We'll see how long it takes to rebuild. :-/

10:30 Started the validate process.
       Delete everything except the source code.
       Compile the stage-1 compiler using the stage-0 compiler.
11:00 Stage-1 compiler is ready.
       Compile all the Haskell standard libraries using stage-1 compiler.
11:30 Standard libraries are ready.
       Compile the stage-2 compiler using the stage-1 compiler.
12:00 Stage-2 compiler is ready.
       Compile the doc-gen program.
       Generate the HTML documentation.
12:15 Start running compiler test suite.
12:50 All tests completed successfully.

NB:

* The stage-0 compiler is the binary package that the Linux package 
manager installed. (GHC 6.8.2, as it happens.) The version I'm compiling 
is 6.11.20080214.

* The stage-1 compiler is linked against the stage-0 Haskell standard 
libraries. Then we recompile all the libraries using the new stage-1 
compiler. Last we recompile the compiler itself, linking against the new 
libraries we just built (i.e., we make stage-2).

* When I did a "normal" build yesterday, it made 2 copies of every 
Haskell library - a normal copy, and a copy with profiling enabled. 
(Enabling profiling makes the compiled stuff 2x bigger and 12x slower.) 
The validation build didn't bother with the profiling step, making the 
process about twice as fast.

* Curiosly, the normal build seemed to build a version of the compiler 
with profiling enabled - I'm not sure why the hell it would do that, but 
still. The validation build didn't seem to bother.

* The normal build also generated the HTML documentation for the 
compiler itself. This validation build has built the library 
documentation and the GHC API documentation, but not the user guide. 
(The user guide is quite fast though; just translate DocBook to HTML.)

I love the way that every now and then, you see a command line that 
starts with "ld" or "ar" and goes on for 3 pages. o_O Pretty crazy! Well 
anyway, after half an hour of compiling the compiler itself, the 
resulting binary is about 30 MB. (The stage-1 compiler is smaller, but 
then it does have several features disabled.)

Now, do I dare run the benchmark?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Sun, 15 Feb 2009 11:16:59 +0000, Orchid XP v8 wrote:

> (Of course, as well as compiling the compiler twice, it also compiles
> all sorts of other build tools, the standard libraries twice, builds
> HTML documentation, and sweeps your bedroom floor...)

Maybe I should run this as well, the cat tumbleweeds are quite prominent 
on the floor here by the computers. ;-)

Jim

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> I love the way that every now and then, you see a command line that
> starts with "ld" or "ar" and goes on for 3 pages. o_O Pretty crazy! Well
> anyway, after half an hour of compiling the compiler itself, the
> resulting binary is about 30 MB. (The stage-1 compiler is smaller, but
> then it does have several features disabled.)

You could try:
strip -g binary -o new-binary

strip -g strips a binary off of any debugging info it might have.  Or -s to
strip even more possibly useless info on a production binary.  Don't forget the
-o new-binary or it'll strip away and write the stripped binary to the same
file.  You can backup yourself if you're unsure.

stripping generally yields severelly smaller binaries.  That's supposing the
whole build process already didn't perform such step (I think it's standard to
leave the debugging info if you don't provide a -g flag).

> Now, do I dare run the benchmark?

heh, why not? ;)

Post a reply to this message