A89: Re: TI-GCC IDE issues


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

A89: Re: TI-GCC IDE issues




I haven't tried the IDE yet; but I assumed it had been written in C.  You
say it's not: so what is it?

Tyrel Haveman,
tyrel@haveman.net
President
Haveman Computer & Internet
http://www.haveman.net/

----- Original Message -----
From: "Scott Noveck" <noveck@pluto.njcc.com>
To: <assembly-89@lists.ticalc.org>
Sent: Friday, June 30, 2000 12:26 AM
Subject: A89: TI-GCC IDE issues


>
> Two major issues with the most recent TI-GCC IDE (included in TI-GCC 0.7)
> which I think are important to bring up on this list:
>
> 1.) This version of the IDE is very, very unstable with syntax
highlighting
> turned ON.  It's too bad, because I was starting to like it.  I often have
> crashes when deleting lines, and I've got a repeatable one now.
>
> Open TI-GCC.  Open the automatix project file (the source is included in
the
> zip).  With syntax highlighting ON, scroll down a bit in the "Main
Program"
> file to line 37 and you'll see one line that starts with "long," followed
by
> a blank line and two more lines beginning with "long."  Move the cursor to
> the blank line, and press del - whammo, crash.
>
> You cause another, similar crash with the same source file.  This time, go
> to the "Interrupts" file.  See the blank line on line 25?  Delete it.
> Ooops!
>
> If only the IDE were written in C, I'd love to be able to fix that and add
> some features myself. . . =(
>
> 2.) [big thanks to Wrath on this one, since I'm too lazy to look up these
> facts myself)
>
> Why is the IDE default - and most people's code - using -O2 optimization
> instead of -O3?  According to the GCC docs, -O3 turns on all optimizations
> that don't sacrifice size for speed.  The majot difference is function
> inlining, which is automatic on -O3 but not done on -O2.
>
> Looking at the Automatix source, using -O2 is gonna make horrible
> performance debts.  Look at this code:
>
> void AddByteMask(byte *Ptr, byte Mask)
> {
>  *Ptr = *Ptr | Mask;
> }
>
> The compiler is actually doing this as a subroutine!  This code should
> probably be hardcoded in rather than used as a fuction, or at the very
least
> used as a macro.  But GCC isn't even inline'ing this - ouch!
>
> That's my rant for the day. . . feel free to comment.
>
>     -Scott
>
>
>




References: