He's outdone himself with this one. Finally, we dont have to wait for the syntax to be highlighted....

It's the IDE like the DJGPP-rhide one? I like to see colors when coding, for example:

printf("%d",var);

printf will apear in yellow, "%d" in green, var in yellow and ( , ) in white... this is very helpful, it's easy to see the different parts in every command.

Yes. You can even define lists of words that will have different colors, for example "printf", "printf_xy", and "DrawStr" could all have another color from the rest. Moreover, you can define different colors for different levels of parentheses.

COOL! I have downloaded it...but it runs in a window, I though it was a DOS program...COOL!!

Sebastian Reichelt, et. al.?

I think most of the people in the TIGCC team (i.e. Xavier Vassor, Zeljko Juric, Jean Canazzi) are actually more important than me.

Trail could lead to Richard Stallman, initiator of GNU movement.

but you're the visual guy! ;) shows you how the PC world works...
On a better use of space:
thanks guys! na TICT too! we love you! :)
---
Cd_Slayer

> but you're the visual guy

This, or the fact that I made the setup program, and therefore uploaded it and sent a mail to news@ticalc.org.

Wow :) There is the source code :) (to the news author: please do include the link to the source package on such news, as Nick used to do-- though I didn't have to search for long)
I'll be able to recompile the 'linker' under Linux, and produce a TiGcc Package for Linux (The compiler now works *very* well, I even managed to recompile the current Prosit kernel on it--BTW Linux will be the _official_ Prosit devel platform, since I don't want to(also cannot) work under Windows), which will even be more powerful than the windows tigcc :-) (what about Fargo, [tie], ...)
For those who would like to test an alternative to the IDE, you can download a windows version of XEmacs ('the Best Editor in the world'), see the link.

> There is the source code

Of course, because it now exists. The full source currently resides only on my hard drive, but I'm going to make a CD (which people can theoretically request) just to make sure the whole 300 MB of my Cygwin installation will never be lost. In case you are wondering, I was the one who repatched and recompiled it, but it wouldn't have been possible without the help of Jean Canazzi. I just thought I'd tell you: Just to be sure that everything really works, include the switches "-m68000 -mshort -fcaller-saves" in the command line. They might not be needed at all (I don't think they actually do anything in this case; the last two of them were from the TIGCC for Linux sources), but then again they might be important in some situations.

> The compiler now works *very* well

This one is for all: There has been one problem reported so far. If you have an empty loop that just checks for _rowread to return something but doesn't have anything in its body, and have optimization turned on, the loop might never return. I hope this can be fixed somehow. You can work around this bug by putting "idle()" into the body.

> For those who would like to test an alternative to the IDE, you can download a windows version of XEmacs ('the Best Editor in the world'), see the link.

I'll try it to compare it with my IDE (which will have a sprite editor soon, btw). Do I really have to download 23 MB, though? This is not fun, really, because I'm running over a relatively slow wireless network at home. Please tell me if there is a less bloated version available somewhere. And I just thought you'd want to know that the link doesn't work because ticalc.org put "http://" in front of it. If you remove that, it works fine.

> If you have an empty loop that just checks for _rowread to return something but doesn't have anything in its body, and have optimization turned on, the loop might never return.

Hmmm... So I need to rewrite _rowread to be a inline hex-array function (like functions from stdio.h) instead of smart macro. GNU C don't know how to "optimize" a lot of hex values casted to a function type (because it don't have a program flow), so it will not cause any "damage" by unwanted optimizations.

Zeljko, how about including the source code to hex-array functions commented out in the header files? That way, if somebody wants to modify or use your original routines, they can do so.

I've already found reason to modify the sprite routines to make them handle grayscale sprites - sure, I could make another function that calls the sprite routine twice - once for each plane - but that would add a lot of overhead. I've also stolen your _rowread for use in one of my sample apps, since there was no need to write my own - I'd hate to see it included only as a hex array, in which case I would have had to waste the time to rewrite it.

All routines which are given as hex arrays are also given as full C or ASM sources in a separate file called "sources", so you can look everything. I thought that it is better not to overload header files itself.

> Of course, because it now exists.
I know about the story :) It wasn't to blame anyone... just to say I'll be able to work.
> include the switches "-m68000 -mshort -fcaller-saves"
Well, actually, not -fcaller-saves, but -fcall-used-d2, as only this is clobbered by function calls, it allows for better optimization :)
Concerning the -m68000, Why in the patch do you set all those defines to 0 ??? (what if I put a 68030 in my TI ??) :

// TIGCC
#define TARGET_68020 0

BTW do you know you can change the default target architecture (to 68000 for example...), saving the need to put a -m68000 flag on the command line. I think it also apply to -mshort...
I'm thinking about including a -mti flag so it changes the defaults (even return convention) only when compiling TI programs...

NTEmacs whould be smaller (thought its interface is prety ugly, but it's Emacs, not XEmacs)... Talking about sprites, (X)Emacs has an XPM mode which allows it to edit .xpm bitmaps, which is worth a look (of course format conversion is needed to have a sprite then, but... And the XPM format is plain ASCII file :) )

ftp://ftp.lip6.fr/pub/ emacs/ntemacs/latest/ (remove the space)

P.S.: Sorry for the broken link :(

> Well, actually, not -fcaller-saves, but -fcall-used-d2

I changed the definition of CALL_USED_REGISTERS in m68k.h so you don't need this. Are you saying that "-fcaller-saves" is definitely not needed? I just took it from the TIGCC for Linux package; I really don't know.

> Concerning the -m68000, Why in the patch do you set all those defines to 0 ???

To (hopefully) disable code to be created for other processors in any case. I think I found out how to declare -m68000 by default now.

> what if I put a 68030 in my TI ??

Yeah right!

> BTW do you know you can change the default target architecture...

I needed to know the order in which the header files are included. Now I know that you just have to look at m68k-coff.h, which includes m68k-none.h, which includes m68k.h. The modification you have to make are probably mostly to m68k-none.h. I found out that none of these header files actually produce any code, so changing defines later has the effect of changing them for the whole compiler.

> I'm thinking about including a -mti flag so it changes the defaults (even return convention) only when compiling TI programs

That would be a good idea, but you might run into some problems since RETURN_VALUE currently does not check for switches. I will try to do it as well.

> I really don't know.
Neither do I.
In fact, I think it is useless.

> I think I found out how to declare -m68000 by default now.
Have a look at the ti-fr forum (the link), and see the patch I made.

> That would be a good idea, but you might run into some problems since RETURN_VALUE currently does not check for switches.
Switches are basicaly things that set bits in an internal variable in gcc (let's call it mflags), I think defining a new switch and doing something like :
#define RETURN_VALUE (mflags & TARGET_TI)?(-mti expr):(+mti expr)
should be ok.

Any thoughts on having a register calling convention? This would be smaller and faster than the standard C calling convention, and would make the performance of C closer to that of hand coded assembly.

Register calling convention will make a lot of troubles, because all TIOS entries expect C calling convention, so it will become nearly impossible to make something like TIGCCLIB.

Why ?
If in the first place the tigcc team had taken the m68k-amigaos-gcc instead of m68k-coff-gcc, it would have been as simple as that:
int myfunc(register int a __asm__("%d1"), register void *b __asm__("%a0"));
Normal fonctions are still called correctly, but functions declared this way are passed parameters in registers (this woul allow smarter library calls...)
But the m68k-coff-gcc doesn't allow it by default, so if we wan't to do it we need to figure out to patch gcc... :-( (btw, I'll have a look at it :-) )

No, you support both. All newer compilers for x86 allow that, and probably most optimizing compilers for any platform will optimize functions by passing parameters using registers.

GCC has no built in support for multiple calling convension in the general source, it has to be implemented for each target. Though not impossible it is quite involved, or at least that's what I recon after a quick glance at the source...