Re: A92: Re: Mac C -> Fargo "C4Fargo Mac" released
[Prev][Next][Index][Thread]
Re: A92: Re: Mac C -> Fargo "C4Fargo Mac" released
David Kühling wrote:
> 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.
I agree, and just incase everyone forgot I started a C compiler that ran
on the computer, and produced txt-asm that could then be compiled with A68k.
It was written in Java though, but if I got enough help I would be willing
to convert it to C++. And I would be willing to start working on it again if
someone else was willing to help.
Follow-Ups:
References: