Oh sweeeet. Phew! You almost had me there necro. Good to know it is still back on track, and those blood stains look awesome!

Yes I think it was fair as well. Warnings were issued and were not heeded which resulted in swift action to take out the bad seed. He was at least not banned from the site which should mean that there is some chance, if not small, that he will be welcomed back. All in all there is no loss here I believe because all he needs to do is prove himself more mature.

Goplat: Believe I have been working on this for some time now and  I have already thought about everything you just said right there.

Let me address some things.

1. z8-GCC has still been in effect and is still being worked on, but it is not z8-GCC anymore because we are not using GCC.

2. C will most obviously not be as efficient as hand-written assembly, but it will provide smaller size than BASIC and much faster speed than BASIC

3. Let me answer you questions up there

Well first off I should address this by saying my development team and I are making a C compiler from the ground up which will support 68K and z80 as the first targets. It will be target-expandable meaning that the compiler will produce programs for any processor that you want to target it to through writing a backend.

Now let me talk about the problems that you have posed above.

1st problem: Calling conventions: There are numerous ways to pass arguments on the z80. Registers, stack, memory. These can be user defined or they can be chosen by the compiler. Secondly I don't think you know this but the z80 in effect actually has  14 8bit registers or 8 16bit registers.

8bit: a,b,c,d,e,h,l,a',b',c',d',e',h',l'
16bit: bc,de,hl,bc',de',hl',ix,iy

Now also another thing which you may or may not know is that ix, and iy can be used in almost every place that hl can be used which gives you 4 general purpose 16bit registers. So that is more than enough to pass parameters to functions as long as you do it smartly.

2nd problem: Register allocation: Basically what you just said is that is going to be more work for me. Well I don't care because I have been turning this over in my head and have came up with some very good algorithms.

3rd problem: Types: int defaults to short. Can you have a long int? Of course. Can you have a long long int? Of course. No need to worry there. It may take more time, but I see assembly programmers using them all the time. Remember it doesn't take that much more time. Maybe 2-4 cycles which isn't that much. You have 6 million cycles in a second on the z80 and 15 million possible on a z80 in the silver edition.

4th problem: Types: I still see no problem. What you are saying is all possible so I really don't see the point in that statement?

Now let me just say. Of course it will be more work to write a z80 target for our C compiler, but it will NOT make over-bloated or even close to unneeded bloating code. It will be aware that register to register loads are faster than constant or memory loads and that will make an effect. SSA trees will be used for other various optimizations internally in our compiler. Final pass peephole optimizations will also be made like the call-ret optimization.

Also remember that programmers will be allow to write there own assembly functions for their programs too.

Trust me Goplat. Anything you can throw at me has already been thought of. I would not continue with this project if it was not possible.

Oh and about that using more memory than it should?? That will not be a problem as programmers will have the option to use bcall()'s over the hand-written z80 assembly C functions provided in the Standard libraries if they truly need it.

One thing I can guarantee you is that the C games will not be as big as their BASIC counterparts and will most be much faster.

TheStorm that is clearly not true as TiLP only gets so many articles because it is a universal calculator program, and that is the same with TIGCC. That is straight from Michael's mouth.
Logs(proof):

QUOTE

... I mean, as BrandonW (I think) mentioned before, ticalc.org used to have a program of the month you might have the best game of the summer the odds would probably favor it I wasn't the one who said that...I was here when someone did, though. but historically it's not at all good yup, I got that afk for coding compare it to 2004 or such and it looks awful by comparison I ponder these issues if I don't feature enough programs, we don't have enough news then but then it's not entirely fair to people years ago who would have gotten the same thing rejected Talk about minute Nspire updates. or the latest minor-minor TiLP version The best game of the summer would be SM 68K shush Windows Fax and Scan from the Start menu...finally... I know I post too many TiLP articles but it has universal calculator model appeal ... in any case, you will be the only file in the most recent updates until an archiver gets around until processing some more Two minutes before! Check the logs! (really small pixels) that's almost as good as featured ...

I would just like to say this to the community.


Michael_V doesn't have to do crap, but he has been taking away from his free time to help the community and keep the community updated for sometime now, so why are we going to get on him for one thing? If I recall he is a volunteer and I would rather not runaway someone who is helping the community in an amazing way. I mean this is like bugging the developers of Blender, GIMP, GCC, or any other free software developers. Do we seriously forget all the food that someone has brought to our plate over a subject as pitiful as a little feature. I certainly wouldn't complain/bug/diss the GCC developers when I am building all my programs everyday with their compiler. It is simple respect!

This is not directed at anyone personally.

Yeah I remember when I first saw this without any of the graphical dressings it was still sweet. Looks like a lot of in-game action.

It was in the works but...