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


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

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





> 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.

  I agree, and that is the crux of my current project.  All this and more will
be available to C programmers under Xinu (assuming my advisor allows this
project next semester, there is still some administrative problems).  The basic
suite of standard C functions is available through Xinu libraries.  Also,
threaded execution, and all sorts of other fun features.  All of this will be
integrated with TI-OS so as to be unnoticable.  Except, of course, for the
memory use: ~30K for the full Xinu system on the Sun3, I'm trying for ~16K for
the full suite (lots of TI ROM routines cut down the neccissary code, and stuff
like networking and files are not applicable).  Also, a smaller installation
will be possible with just the C libraries and minor system support, I'm
guessing about 10K for that.


> 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.

   C4Fargo IS real C, and allows all the possible C structures and problems,
that's because it is just a project loaded in a real C compiler.  MetroWerks is
very cool.  Linking of libraries will be through library glue code, the
routines will just have jumps in them, and a library loader will do exactly
what Fargo does to load libraries, but instead of a relocation table, the
loader will just convert all the glue code jumps.  This works with the
MetroWerks compiler too, since unused library calls will not have their glue
code compiled into the project, and thus not take up space.

   Also, MetroWerks can compile to assembly also, although I've not tried to
assemble the output, I'm sure it would require some editing before an assembler
would accept it.

   Metrowerks also allows Pascal and C++ compilation, it would only be a small
change to the project to setup the system for these languages as well.
 Although ROM calls from Pascal would be unwieldly, requiring some assembly
glue to convert the calls.

Hopefully much more will come out of this project, but it won't be until next
semester regardless.

--Bryan
bcturner@eos.ncsu.edu


Follow-Ups: References: