Re: A92: TI-GCC and Its Design Flaws...
[Prev][Next][Index][Thread]
Re: A92: TI-GCC and Its Design Flaws...
But remember that it is the way for tell to tigcc compiler that
need use a library call. ;)
Aaron Hill wrote:
> 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)
References: