[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [MiNT] Re: GCC



> From: owner-mint@fishpool.com [mailto:owner-mint@fishpool.com]On Behalf
> Of Johan Klockars
> Sent: Tuesday, February 23, 1999 4:39 PM
> To: mint@fishpool.com
> Subject: Re: [MiNT] Re: GCC
>
>
> As has been said, this thread really doesn't belong here, but...
>
> > > I once had to modify a program because PureC (I don't think
> it was back
> > > in the TurboC days) complained about something to do with namespaces.
> ...
> > Interesting. So far I haven't come across a PureC problem which made the
> > compiler itself non-ANSI...
>
> Well, this problem (whatever it was exactly) definitely was a violation of
> the standard.

Well, I would like to see that... :-) I'll try to test it this evening.

> > > I also don't like to use C as a 'macro assembler', which is
> more or less
> > > necessary if you want to get decent speed out of PureC compiled code.
> > > Take a look at dejanews for my Usenet articles comparing the three
> > > compilers mentioned here if you want to see what I mean.
> >
> > I am very surprised to hear this. My experience is that PureC
> code usually
> > is smaller and faster because of the parameter passing model.
>
> If you write code that calls lots of small functions that can indeed make
> PureC faster than at least GCC (Lattice can pass in registers as well if
> you tell it to). On the other hand, if speed is important - why are you
> calling a lot of small functions, anyway?
> Also, GCC could inline them for you...

But that would make the code larger.

Fact is, back when it was possible to compile MiNT with PureC, the resulting
code was both considerably smaller and slightly faster... (just to make this
thread a bit MiNT related :-).

> The problem with PureC is that it really doesn't optimize at all, though
> it's pretty good at register allocation.

Yes, that's my understanding as well.

> The test program I've used in my most recent compiler comparison tests
> (I don't think dejanews goes back long enough to find the earlier ones)

Indeed.

> is as follows. A seemingly simple program which never the less shows
> a _very_ large difference between PureC and Lattice/GCC when it comes
> to the code generated.
>
> #define ROWS 25
> #define COLS 25
>
> void main(void)
> {
>         long i, j, k;
>         long array[ROWS][COLS];
>
>         for(i = 0; i < ROWS * COLS; i++)
>                 *((long *)array + i) = 0;
>
>         k = COLS * ROWS;
>         for(i = 0; i < ROWS; i++)
>                 for(j = 0; j < COLS; j++)
>                         array[i][j] += i * k;
> }

Could you post the GCC code? I'll check with PureC.

Regards, jr