Author Topic: HACC (Read 23669 times)

Halifax · « **Reply #105 on:** September 05, 2007, 01:56:00 pm »

Yeah, it is going to support Applications natively since no SMC will ever be present in any code generated.

@bfr: Yeah D looks alright. Some people have made some OpenGL tutorials with D, but overall I think it just looks stupid. Like which do you think looks better?

int a[100];

or

int[100] a;

and

int *a;

or

int a[~] = void;

@Liazon: I figured heh.

DJ Omnimaga · « **Reply #106 on:** September 06, 2007, 02:46:00 am »

Nice to see it will support apps. I hope it still supports asm programs too tho o.o

btw Idk if i asked this alerady I am too lazy to check back through all previous pages but which shell will this compiler support? I mean, mirage, ion, crunchy, dcs

I will make this a Hacc project forum asap btw

darkfire · « **Reply #107 on:** September 06, 2007, 05:27:00 am »

QuoteBegin-Halifax+4 Sep, 2007, 13:36-->

QUOTE (Halifax @ 4 Sep, 2007, 13:36)

@calc84maniac: I understand that, but what you said was a little flawed. JR has a 25% chance of being faster literally. Which I don't really know if you meant literally though by your post. Anyways this is why the decision is up to the programmer.

Really there is no sense in basing the speed of your routine off of that unless you know that it is more likely to be false which is most definitely not applicable in a compiler!

Also just so you know that logic applies to any command supporting conditionals.

@DJ_Omnimaga: No the TI-89t can have C++ if some builds the compiler. Any system can have C or C++ if some builds the compiler. But the problem is no one wants to build the compiler because frankly parsing C++ sucks and is very very hard.

I can't find the link now but I remember Kevin Kofler saying that programming for the 89T in C++ is just not feasible. The amount of header space that a c++ program needs it to much. A simple command such as cout << "Hello World" would be in the kilobytes range. Which compared to the printf("Hello World") or better yet the Drawstr (which use the calculators built in features), which compiles to just bytes. Is just way to big. Making compiler wouldn't be terribly difficult some just has to make the linking library's. Tigcc's compiler isn't made from scratch its derived from GCC. Since most people when they make games for the 89 just use the library functions. Adding the extra features that c++ gives (and the extra compile size), Is just out the question.

DJ Omnimaga · « **Reply #108 on:** September 06, 2007, 05:40:00 am »

Ah ok I see, i guess thats a good point really. I would not like if I did a tunnel game and it ended up 1-1.5 KB huge, if not more, while i can do a TI-BASIC one in less than 200 KB

As I said if C do the job, I guess there isn't much need for C++ anyway.

Welcome here darkfire btw.

Halifax · « **Reply #109 on:** September 06, 2007, 01:44:00 pm »

darkfire: I thought that was covered. I guess I didn't specify. Either way contrary to popular belief TIGCC was not just another backend, but it was in fact derived from the GCC grammar files. But way more work was done than just adding a simple backed.

Secondly, G++, just like its brother GCC, provides a great interface, and a hand written parser for C++ since Bison pretty much sucks in generating parser files from complicated grammars, which is also the reason since 3.x the GCC parser was hand written. Either way the language is never bloated because of the language. The language is bloated because of the compiler. cout << could be compiled into bytes too, and it is. Just check out the code generated. And if it isn't tight then are you even using parameters to the compiler?

Also a C++ compiler is deadly hard to make. Making a C++ grammar file is deadly hard to make, let alone actually creating the parser. If you don't believe this, then I recommend you try it sometime

Really C does *do* the job...I guess...unless you try to make your own abs() macro. Try it

Oh and by the way take into account that a person could pass the value abs(x++) which means in your macro you can only use the parameter once, or it will expand to 3 adds.

Either way, I am just planning out still a little. One of the other developers is working on the lexer currently so soon I *should* have an example of the lexer. As long as no one gets lazy.

I am just planning, and still working on the trees. Changing from binary tree to a N tree is no joke man...but once I get out of school tommorow I will have the weekend to finish up all the tree crap.

calc84maniac · « **Reply #110 on:** September 06, 2007, 02:05:00 pm »

Signed comparison is cinchy... Just compare the first number to [the second number with top bit inverted] and check p/v.

Halifax · « **Reply #111 on:** September 06, 2007, 02:08:00 pm »

calc84maniac: Ummm...what? Dude I am talking about implementing it as a macro for compilers, not assembly.

calc84maniac · « **Reply #112 on:** September 06, 2007, 02:19:00 pm »

QuoteBegin-Goplat+1 Aug, 2007, 18:28-->

QUOTE (Goplat @ 1 Aug, 2007, 18:28)

I've thought about this subject a bit and I don't think a C compiler for Z80 would really be practical. The Z80 architecture is badly suited for C (or any other compiled language, really) for several reasons:

in C, the normal way to pass arguments to a function is on the stack. On most modern processors, you have a stack-relative addressing mode, so this is fine. Z80 has no easy way to access elements of the stack below the topmost, so the only sensible way to pass things into a function is through registers. But the question of which registers are best to use is dependent on the function itself, and to some extent its callers. C requires standardized calling conventions in order to be able to have separate compilation of multiple source files; a compiler can't generate the code to call an external function if it doesn't know how that function expects its arguments passed.
Register allocation on the Z80 is a very complicated problem. On most processors, registers have few if any differences between them - if it works on "R0", it works on "R7". On the Z80, every register has its own special purposes, so deciding what to put where becomes more complicated.
When C programmers want an integer, they usually just type "int". This poses a problem for the Z80, since "int" has to be at least 16 bits long. On today's processors, 8-bit, 16-bit, and 32-bit operations are all the same speed, but on the Z80 anything bigger than 8-bit takes up more time and space.
Also, in C integer types are signed unless you explicitly say "unsigned". More often than not, it doesn't matter whether a variable is signed or unsigned so programmers just use signed integers to save typing. Unsigned comparisons can be done easily on the Z80 (just use the carry flag), but signed comparisons require that the sign flag and parity/overflow flag be XORed together. Modern processors have conditional jump instructions that do just that; the Z80 doesn't.

I strongly doubt that a C compiler could ever produce Z80 code anywhere near as well as a person writing assembly could. As a result, C games would require a lot more memory, which is in short supply on the Z8-based calculators.

Oh dang, I forgot how long ago that quote was... @_@ oh well, here.

Halifax · « **Reply #113 on:** September 06, 2007, 02:40:00 pm »

Oh yeah, lol, it is best to quote a post when it is from that long ago.

Thanks for clarifying though!

Also just noticing something about Goplat's post.

QUOTE

I strongly doubt that a C compiler could ever produce z80 code anywhere near as well as a person...

Haven't you checked lately...GCC, or any other compiler you can think up, can't do that either.

Oh and by the way Goplat. For one thing, the C language can't even do rotations, which I plan to put in this compiler. I don't know why it wasn't included in C...or any other language for that matter. o.o

bfr · « **Reply #114 on:** September 06, 2007, 03:55:00 pm »

Halifax, what do you mean by "rotations?"

DJ Omnimaga · « **Reply #115 on:** September 06, 2007, 06:06:00 pm »

Moved to the new HACC forum!

calc84maniac · « **Reply #116 on:** September 07, 2007, 09:55:00 am »

I believe he means "RRC/RLC/RR/RL" rotations.

Halifax · « **Reply #117 on:** September 07, 2007, 12:13:00 pm »

Yup calc84maniac is right. If you want rotations in C then you have to software implement them, unlike shifts which are built into the language. I don't know a processor that doesn't support shifts and rotations so I really don't know why it wasn't added to the C language.

Liazon · « **Reply #118 on:** September 08, 2007, 06:04:00 am »

rotations will probably be more useful for z80 since it really depends on them for a lot of things (like tilemappers)

Delnar_Ersike · « **Reply #119 on:** September 08, 2007, 06:37:00 am »

Kind of off-topic note: shouldn't this be moved to the Halifax's Projects subforum?

Author Topic: HACC (Read 23669 times)

Liazon

Delnar_Ersike