A92: Re: Mac C -> Fargo "C4Fargo Mac" released

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

A92: Re: Mac C -> Fargo "C4Fargo Mac" released




   Ok, I've gotten enough mail about this, so I'll just post it here (sorry to
those not interested in C development on the TI-92).

   First though, I have to rebuke Nielsen's comment about the efficiency of C
compilers.  Yes, it is true that C is not as efficient as assembly, but due to
the severe lack of assembly skills in the TI community, I'd rather have lots of
semi-efficient but very interesting programs rather than the current, very
sparse, batch of assembly programs (which I must say, are not very memory
efficient even though they ARE in assembly).
   Hopefully, with C project kits, and some creative programmers, we can have a
thriving software comunity.  Smart assembler programmers could use their brains
to write devastatingly fast utility procedures for the C libraries which are
used by the C programmers to write devastatingly fun games and utilities.

So, anyway, off my soapbox;

   To create a C kit, you need a compiler which generates 68k object code, and
allows inlining opcodes or assembly.  Also, the compiler must not generate
object code which is fixed-memory dependant.  That means the code uses relative
jumps rather than absolute jumps (BSR *+123 instead of JSR $100123).
   Metrowerks CodeWarrior is just such a compiler.  Also, as an added benefit,
globals are compiled as reletive offsets to A4 or A5.  This is used by
reserving some empty space in the code to store the globals, and then setup A4
to point to it before jumping to the main code.
   Most compilers should have the option of compiling 'relocatable' code, or
non-static code.  This will produce the relative jumps that are needed.  Also,
you can avoid the entire global problem by building stack frames for your
procedures.  Main would create a large structure on the stack and pass a
pointer to the structure for every procedure that needs the global variables.
 The value of these stack globals would not be saved across calls to the
program, but the program would also be smaller since it would not have to allow
space for the variables in the code.  Other methods for establishing globals
through C is possible, contact me if you want some ideas.

   Once all this is figured out, create a project that has a header, the code,
and a trailer.  The header contains all the data Fargo needs to recognize a
program, plus empty relocation tables, and empty library tables.  The trailer
has the data that is found at the end of all Fargo programs (about 10 bytes).
 I don't know what it's for, but the vars don't send to the calc without it..?
   In CodeWarrior, the header and trailer are procedures compiled along with
the main program.  Unfotrunately CodeWarrior will strip code that is not
executed to save space, so I had to create a chain of jumps which ensured that
each prodecure got executed and thus compiled into the project.  Along the way,
I setup A4 to point to the global data.
   Lastly, libraries would be loaded, relocated, and library calls would be
mapped, but this feature is not yet implemented (y'all are too impatient).
 Then the main code is called and the program runs like any other C program.
 The RAM header file maps memory addresses to names which I believe will help C
programmers to understand how to use the calculator's exisitng features.


   Hope this explains the C Kit well enough for some other kits to get
developed.  If you do get another kit working, let me know so we can
standardize them, no one needs a kit war (especially not like the OS war on the
'85s!!).

--Bryan
bcturner@eos.ncsu.edu
Follow-Ups: References: