A92: TI-GCC and Its Design Flaws...

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

A92: TI-GCC and Its Design Flaws...


I would first like to congratulate the author of TI-GCC on his or her
efforts to open up the programming options for us.  Awhile back I had
tried to get GNU C to work.  The solution was simple in concept, but
the amount of work to implement was too much for me.  Now this TI-GCC
is a nice start, but I think there are some flaws in the design.  The
GNU C compiler is known for its platform-independent nature.  Even
the assembler is platform-independent.  It becomes platform-specific
when the object code is produced.  From the few bits of source I have
seen on the list, there are some TI-specific statements that could be
removed.  Look at this:

#define clrscr graphlib__0005

Firstly, macros and macro programming have long since been dead.  It
was a great way to program, but there were so many problems with its
use.  Debuggers rarely knew how to break apart macros, so finding any
bugs with macro expansion became difficult.  The original programmer
might have half a chance understanding a piece of old code, but the
use of macros made programs very difficult to understand.  Recently I
began to program in C++; this has taught me several ways to clean up
my old macro code.  Not all uses of macros are fixable, but the most
common uses can be done using other techniques.  The code fragment
above is one of these difficult macros.  Macros are nothing more than
string substitution.  With that in mind, the following function calls
should be equivalent.

clrscr();
graphlib__0005();

The macro allows programmers to give another name to a function that
may be difficult to remember.  If that is the desired effect, then a
better solution is to simply make a function that calls the other.

void clrscr( void )
{
    graphlib__0005();
}

Concerned about speed?  Sure this code would execute slower, but add
the "inline" keyword and the function call to clrscr() resolves down
to the desired call to graphlib__0005().

The second problem is the function name, graphlib__0005().  Why does
the compiler need to care where the function comes from?  That is why
there is an "asm" keyword.  Instead of using graphlib__0005(), simply
define the clrscr() function using assembler.

void clrscr( void )
{
    asm("jsr graphlib::clrscr");  // Or something like this...
}

I'm not familiar with the 89/92+ naming convention for library calls,
but you should get the idea.  This method requires no modification to
the compiler whatsoever.  Don't forget "inline" to make it faster!

Take a look at this code fragment:

int _ti89, _ti92plus;

I am not sure why this is needed; my guess is that these definitions
instruct the compiler to function a particular way.  If the 89 and
92+ have that much difference, then they should be two different
target platforms.  So if I remember my GNU C, you would have a 68k
machine type (or 68k-TI to set it apart from Amiga 68k or Mac 68k).
Then you will have three target platforms--89, 92, and 92+.  Perhaps
I have forgotten too much, but you should not have to use these ints.
If you still wish to have something like this, I'd suggest using a
command-line define (or in code #define).  That way you could write
your programs to compile based on the machine type.  Perhaps you may
use the #pragma statement, which only has one obsolete use.  Anyway,
it is not good programming to have these ints.

====
Aaron Hill (Redmond, WA)
E-Mail: serac@lightmail.com
IRC-Nick: Serac (on EF-Net)
Follow-Ups: