Re: gcj and xgamestation

[Martin Brain <mjb at cs dot bath dot ac dot uk>]

> Thanks, unfortunately I don't think I have the expertise to do this.  My experience is almost all
> with high level languages.  This is one of the reasons I am intrigued with the xgamestation
> project, it seems like a great way to learn more about the bits and bytes and low level
> operational aspects of computers.
Can I advise you read the manual for a simple RISC like machine and
possibly get yourself one to play with (at a low level).  I'd strongly
recommend the MIPS 4K series, these days you can pick up and SGI Indy
without too much difficulty and they are (at the processor level - and
IMHO) one of the most elegant and functional designs ever created.

> So, my understanding is that the way gcc, or any c compiler, works is to take c code as text
> files, compile it and link it such that in the end, you have an executable that will run, without
> any external files, on the machine it was compiled for.
Ummm... depends what you mean about 'external files' it may well link
into run time libraries (like libc - see /lib and /usr/lib and
http://www.tldp.org/HOWTO/Program-Library-HOWTO/index.html if you're
into this Linux thang).

> It runs (correct me if I'm wrong) because by the time it is compiled to an executable it is pure
> machine code.
Broadly speaking yes.  Although there is no reason why you couldn't
write a back end to throw out whatever code you wanted.

> Typically these files are bigger than if they had been done in assembler,
Yes, no, maybe.  You can't really make this kind of statement. 
Typically a compiler produces less optimal (which may mean larger) code
than someone writing the same small section of code but when you're
talking about whole programs there are so many other factors (IE the way
someone programming in assembler will write and structure a program is
different to someone writing in a HLL).

> but with advances in
> compilers over the years my impression is that it is not a huge difference.
Yes and no - optimisers can often turn out code that is larger than the
unoptimised code but faster... or you could optimise for space and thus
get smaller but slower code.  IMHO you can't really make general
statements like this.
 
> So I would assume that gcj would do the same thing, in terms of taking a text syntax (in this case
> java, which is supposed to be close to c)
In syntax and appearance - and IMHO that's about it.

> and converting it into machine code through a compiling
> and linking process.
Yes if you compile to machine code - you can also compile to Java byte
code.

> So why would a "Hello World" program in gcj compile to an executable that is larger than one
> created by gcc, or any other c compiler or really any other programming language compiler?
Because what you're implicitly asking the computer to do is different. 
Some languages have lots of extra intialisation to do, other run time
overheads, etc.

HTH.

Sweet Dreams,
 - Martin

PS Sorry - I have a feeling this is rapidly getting OT.