[A86] Re: SDCC v2.3.0
[Prev][Next][Index][Thread]
[A86] Re: SDCC v2.3.0
On Mon, 15 Oct 2001, Henk Poley wrote:
> And basic input needs only a little wrapper to put A into HL (return
> register).
>
> > Graphics could also be done with little difficulty just in C. All you
> > would need to for the TI-85/TI-86 is to draw them into the screen buffer
> > at $FC00. You don't need even one ROM routine for this. On the lower
> > calculators, you'd need to use use one buffer copy routine, but that is
> > still just one simple ROM call.
>
> Could off coarse be done, but I think the writing in assembly gives you a
> bigger freedom in what you can do, which basicaly means that plain-asm
> routines will be faster and smaller.
>
> > The graphics routines included in the TIGCC library are themselves
> > written in C, and just directly access buffers like this. Of course, if your
> > compiler tends to produce bad code, that might not be such a good idea.
>
> Not exactly bad code, it's just the 'things that you can't do efficiently
> in C' that give the problems. Do note the idea of David Philips, to use the
> higher language as 'glue' only.
Though just how much you can't do efficiently in C depends on how
efficient the compiler is. Even if the graphics routines take 2/3 of the
time and are written in highly optimized assembly, if the remaining 1/3 of
your code takes 4 times as long due to the use of a bad compiler, the
whole thing will take twice as long to run. And even if it is only 1/3 of
the time, it will probably be more than 1/3 of the space, causing the
program to be huge. Which is why I have said a whole bunch of times that
a compiler generating unoptimized code will lead to problems.
Of course it might be that graphics routines are the one special thing
that the compiler generates really bad code for, though it is kind of hard
for me to see how that would be. It is certainly possible to write a
sprite routine is C which will be very poor, but an equivalently designed
one in assembly would probably be very slow also.
If the graphics routines really are highly optimized ones, then the
library might as well be a library for anyone (like genlib on the 68K
calculators), not just a library for C programmers.
> > Then again, if you are writing hugely complex generic graphics routines,
> > that might not be so efficient either as the code would need to handle
> > every imaginable case, when it might be much better for a routine to be
> > specifically adapted to the specific needs of the program.
>
> A nice example for this is 'printf()'... Full version is 2-3kb in Z80.
> (Yes, there will be lots off people who react to this with "wtf do we need
> printf()?")
>
> Most people will even share the z88dk's sprite routines to this, because
> they can draw with variable width and heigth (most spriteroutines I've seen
> are 8x8 or 16x16 only).
Some programs might want one of those routines, so for them a variable
routine is not a good idea (though it's hard to imagine how it would
matter much). And believe it or not, simply drawing sprites is not the
only thing graphics-related anyone would ever do.
In any case, there are numerous programmers who will believe that their
own favorite sprite routines are better than yours (even if yours really
is clearly better).
> - Compiler means:
> + Faster creation of programs.
> + You can reuse code.
> + You can program for all of the (Z80) Ti's at one time.
> + 'Dummies' can use it too.
> + You have something to built routines for... (think about it...)
You can reuse code in assembly also, and assembly is portable (with the
exception of I/O routines, which could be put in a library for assembly
programmers as well). What I really worry about, though, is what kind of
released by 'dummies' will end appearing in mass quantities.
Though what I really meant to ask was what kind of programs you think
should be written with the compiler.
References: