Re: A83: Ti8xcc [82/83/83+/85/86]


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

Re: A83: Ti8xcc [82/83/83+/85/86]



Another big mail, sorry again.

I think you have convienced me, but first I'm going to complete my ROMcall reference (as far as I can by myself), and making
Ti8xcc Standard v1.0, and
Ti8xcc Beta v1.1, and
Ti8xcc Developers Edition v1.1
 ready to post on the internet.

I've already some ideas to make it possible to use TISCO for all calcs.
TISCO uses TASM, so you can use macros in assembly. TISCO itself can also use macros, so you can make a general header-file for each function, which "#include's" the necesairy file(s) for the calculator type,

example:
----fastcopy.h----
#ifdef __TI82__
#include 82fstcpy.h
#define RedrawScreen asm("\tcall\tfastcopy"
#endif

#ifdef __TI83__
#ifdef ION
#define RedrawScreen asm("\tcall\t_IonFastCopy")
#endif
#ifdef SOS
#include 83fstcpy.h
#define RedrawScreen asm("\tcall\tfastcopy"
#endif
#endif

#ifdef __TI85__
..
..
#endif

#ifdef __Ti86__
#define RedrawScreen asm(";don't do anything")
/* calculator takes care of this by itself,
* which causes flicker :(
*/
#endif

We can also invoke the optimizer (copt) which is used in Ti8xcc to add new optimizations (if we find any).

----------
> Before I begin to respond, I'd like to point out that none of the Z80
> compilers for the calculators come close to hand-written assembly code in
> their code generation.  So, it's clearly still best to use assembly
> language.

Okay, I agree. But I think that introducing a/some higher language(s) is
usefull for the people who can't program in asm (find it difficult to learn).
*** Phoenix II Ti-89/92(+) is made with Ti-GCC (isn't it?)***

> > The next thing, I agree that TISCO generates the best code, but:
> >
> > 1. TISCO hasn't got any compiler-sources with it, Ti8xcc does have these.
> > (TISCO is made back in 1998 so big chance that the sources have been
> > deleted in the mean time). I think this is a major disadvantage.
>
> Right.  The lack of source code is a big problem if anyone wants to make
> major changes to the compiler.  However, if anyone plans to be making
> large efforts to the compiler, I don't think that the TI8XCC source is the
> best place to start, because of disadvantages like poor code generation,
> lack of structs, and limiting to one level of indirection (what?).

I chose Ti8xcc because it was the most complete 'C'-compiler I could find, and it was already for 2 calcs (portability). But this lack of structs is really anoying (just try to make decent file-handling routines without them...).

> Instead, if a major effort is to be made, the best place to start would be
> with GCC.  Since GCC doesn't already support the Z80, this will take more
> effort than was needed to make the 68K TI-GCC.  However, GCC has now been
> ported to one 8-bit processor (AVR), so all the foundation work for
> getting it run on an 8-bit processor has been done; all that's left is to
> make Z80 CPU definition tables (basically, just a symbolic list of all the
> instructions and what they do) and probably to write some new code
> generation strategies.  This is of course a major undertaking (as GCC is a
> very complex program) but it will undoubtedly produce a better compiler
> than we'd get just be making a few enhancements to the compilers that
> already exist.

Okay, anybody who wants to help, I would suggest?

> Besides, it may very well be possible to get the TISCO source code anyway,
> as you have mentioned below.

I've mailed to the adresses mentioned in the docs, but these adresses don't exist anymore. I've searched the web and I found 5 other adress from persons with the same name. Two have already bounced back, maybe I've some luck with the others.

> > 2. TISCO is made for the Ti-86 only, Ti8xcc is for the 86 and 83. It has a
> > more modular approach in the include files, so it can be easely ported to
> > the other calcs. I even think that without altering the source code it is
> > impossible to use TISCO for another calc type (it only uses the Ti86xxx.inc
> > files), although there is a quick hack for that (incs.tis).
>
> I don't think targetting TISCO to another calculator will really be very
> hard at all.  Even if we can't change the compiler source code, it would
> not be very hard to write another program which will read in the output of
> TISCO, and replace the top of it with stuff appropriate for another
> calculator.

Okay, I've told something about this already. BTW if you make a file called 'incs.tis' It will be included instead of the Ti86xxx.inc's (and also the "#include's" mentioned in incs.tis).

> The only C++ characteristic (that I've noticed) is the ability to use
> // for a comment, which doesn't really confuse things that much.

I think I got a bit confused because of the 'codeing style' of the programmer, I normaly write a bit more 'readable' (for me although).

> > 5. TISCO is built like an advanced assembler. Most instructions are not
> > 'C', but more some other name for a (couple of) assembler instructions.
> > Ti8xcc is a 'true' Small-C compiler.
>
> I don't really know exactly what you mean, but I'm fairly sure I don't
> agree.
>
> The following statement is quite valid in TISCO.  If you think this is
> not 'C' but just some other name for a (couple of) assembler instructions,
> then you should just compare it with Small-C's complexity.
>
> v = var2->next->next->data->d;
>
> Where everything involved is a structure containing the member being
> used.  Right here we have dereferenced pointers 4 times in a single
> instructions, using data items of three different types.  This is by no
> means the work of an advanced assembler.

The way I look(ed) at this is more because of the way the maker of TISCO uses it's compiler, ex:

void main ()
{
   uint2OP1(2);
   uint2OP2(4);
   dispOP1();
   FPDIV();
   dispOP1();
   FPSQUARE();
   dispOP1();
   INTGR();
   dispOP1();
}

ûhm, not very 'C-like'....

> > 6. Ti8xcc peephole optimizer can be 'changed' (new optimizations can be
> > added), the one on TISCO is only accesible via the source code (which we
> > don't have)
>
> Right, but it would take *a lot* of work adding optimizations to fix all
> the terrible code generation and make it anywhere near TISCO.

Yep, but I've got somewhere already, I just have to fix a couple of bug's that slept in. But I agree that some other optimizations like "dead code elemination", will be very difficult to implement in Ti8xcc.

> > 8. nearly all of TISCO is not finished, Ti8xcc is a bit more like a
> > 'comercial' compiler.
>
> Oh yeah, we need to think of ourselves as 'commerical' to get anything
> done.  Whether or not it is 'finished' isn't what's important (in my
> opinion), but rather the quality of the current version is what matters.

Ûhm, tell me another way to express the difference (so I could use it a next time). It wasn't my intention to get payed for using the compiler or something, just expressing the differnce between good, and 'less good'...

> > 9. Ti8xcc is NOT BETA (TISCO has the version number 0.0 hehehe...)
>
> Yes, but do version numbers, presence/absence of 'beta' really mean that
> much?  Not really.  Different programmers number things different
> ways; some people will always call the first version 1.0, even if it
> doesn't work well.  Others spend a long time in the 0.x stage (there are
> plenty of high-quality calculator programs out there with 0.x version
> numbers).

Yes, but 0.0 is a bit too low I think...

>
> ========== NOW FOR THE EXAMPLES =========
>
> In addition to TISCO and TI8XCC, I'm also throwing in TCC.  This is a
> compiler which is TI86-only and doesn't support structures, but otherwise
> supports a syntax close to C.

We have also the following C-compilers: