Re: A92: Re: Mac C -> Fargo "C4Fargo Mac" released
[Prev][Next][Index][Thread]
Re: A92: Re: Mac C -> Fargo "C4Fargo Mac" released
Bryan Christopher Turner wrote:
> 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
It would perhaps be useful, to program a C-Compiler, which produces
assembler-output, which can be compiled by Fargo (So there will be
almost no compatability problems). It would be very good, if this C
would be very ansi-c like (not like TIC), to be able to compile
pc-programs for the ti-92. To achive this, it would be neccessary, to
program the standard c-librarys, with output, fileopen ... functions.
These library shouldn't be linked with every program for memory efficent
reasons, but should be stored at the ti-92 just as fargo-libraries.
That's why the c-compiler would perhaps need a new keyword like e.g.
externlib, which defines a function as a member of a library. This
keyword would then be used, to define the functions in the header files,
for example in stdio.h:
externlib stdiolib void printf (const char *str, ...);
This wouldn't be like real c, where there are only few libs, which are
very big, and which are linked with every program, but it would cost
very low memory, because you would only need the librarys used by the
program.
Because the ROM is programed with c, all rom-functions can be used by
the c-program, if they use the c-calling-conventions.
Follow-Ups:
References: