Omnimaga

Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: Halifax on January 20, 2007, 07:50:00 pm

Title: HACC
Post by: Halifax on January 20, 2007, 07:50:00 pm
Well after polishing up my C++ skills I figured as a little side project I would work on this. I have already made a command-line interpreter that finds out what file to read from and what file to write to. I have also got a basic parser setup that finds all C functions in a given line I just need to setup how it compiles to assembly and dynamic memory allocation. Is there anything you guys would like to see in this?
Title: HACC
Post by: CureDesu on January 21, 2007, 02:50:00 am
If you do this, you will be my hero... Seriously, do it!  O_Oshocked2.gif
Title: HACC
Post by: trevmeister66 on January 21, 2007, 03:20:00 am
QUOTE
If you do this, you will be my hero... Seriously, do it!

:evil:evillaugh.gif:evil:evillaugh.gif:evil:evillaugh.gif

What he said.
Title: HACC
Post by: Liazon on January 21, 2007, 03:42:00 am
Definitely.  This realm still needs lots of work seeing as few to none of the existing C z80 compilers have displaced the need for ASM programmers.
Title: HACC
Post by: DJ Omnimaga on January 21, 2007, 05:07:00 am
wow amazing, something like TIGCC (of course restricted to 83+ limitations) would rule the world of z80 calcs!
Title: HACC
Post by: Halifax on January 21, 2007, 09:01:00 am
Yes thank you guys but I don't exactly know how TIGCC compiles and stuff but I will make this so that it compiles into Assembly code and then it will compile that code with TASM and Devpac83 so all you need to do is write the C code and compile.

NOTE: I don't know if I will be able to use typedef but also another note is that it will have inline assembly also so you can setup ASM routines to work with zC80. I am currently worknig on dynamic allocation with the 'int' function and once that is done making the rest should be easy riding :)smile.gif

I don't know if I will be able to include typedef and some other complicated C stuff like union and structure pointing :(sad.gif sorry
Title: HACC
Post by: Spellshaper on January 21, 2007, 11:48:00 am
That woud be neat-o.

Time to polish my C++ skills... I think I lost them over the years...
Title: HACC
Post by: Liazon on January 21, 2007, 01:41:00 pm
TIGCC uses GCC as its base for compiling to 68k ASM and then creating binaries.

Most of the existing C compilers for z80 ASM will try to compile into an ASM file (not yet assembled) and then try to optimize the ASM code before creating working binaries.  This is a good idea because trying to use an 8-bit version of GCC (if one exists) probably wouldn't generate very optimized code.

At the very least, I think people would probably want to see basic if, else, while, for, switch/case, etc.  Things like malloc might not be worth the trouble since it's not very feasible on z80.  Most variable use in ASM is either static or for SMC use.  malloc is useable on 68k calcs because their AMS software already has a system to handle dynamic memory allocation.  the z80 calc OS do not afaik.
Title: HACC
Post by: Halifax on January 23, 2007, 11:44:00 am
What I have learned:

This information comes straight from Kevin Kofler. You would only need to write a backend for the GCC compiler instead of a frontend. This is where z88dk failed by only trying to write a frontend for the GCC compiler. Also to compile the bins he has recommended using Binutils. I would want to use 'as' and then 'ld' or 'ld-tigcc'. Also I could port the libraries from TIGCC to z8-GCC with some work for the z80 calcs. Now I have a proposition.

Proposition:

I am looking for skilled C/C++ programmers that are willing to work on this porject with a group. TO keep this project clean, simple, and effcient there will be coding standards, a detailed dynamic list for bug reports and a todo list. This will help with interfacing with different programmers. Now I am only looking for a maximum of 9 programmers and a minimum of 3 programmers including me. If you want to tryout email me at [email protected]
Title: HACC
Post by: elfprince13 on January 23, 2007, 11:58:00 am
you might want to talk to me on AIM at some point, I can help with this.

credentials:
    experience with 20 programming languages (including z80 asm and C)
    working knowledge of memory management, Context Free Grammars, and how compilers work.
Title: HACC
Post by: Halifax on January 23, 2007, 12:13:00 pm
what is your AIM s/n im on there now
Title: HACC
Post by: JincS on January 23, 2007, 05:19:00 pm
I might be able to help:

4 Years C/C++ experience
Intel x86 asm (no z80 asm)
HTML/HP/blady-blah...
Title: HACC
Post by: Halifax on January 24, 2007, 07:24:00 am
JincS do you know how compilers work and about writing backends and binutils??
Title: HACC
Post by: JincS on January 24, 2007, 08:12:00 am
Som e. I'm working on a compiler/interpreter for a scripting language I'm developing. But I'm working on learning more.
Title: HACC
Post by: bfr on January 24, 2007, 08:41:00 am
Yes, you talked to Kevin Kofler like I suggested!  :)smile.gif

Also, remember my other suggestions at Psugen....

QUOTE

Use Flex for the lexer, Bison for the parser and GCC for the optimization and code generation. You don't have to "re-invent" the wheel. You should really talk to Kevin Kofler about this if you need any help; he's really good with this type of stuff (especially considering that he's the lead maintainer of TIGCC).

I'll be glad to help you.
Title: HACC
Post by: Halifax on January 24, 2007, 11:54:00 am
Yeah I talked to Kevin about all your suggestions and he told me that bison and flex are not neccesary. He said all I need is 'ld', 'as', 'gcc backend', and maybe a 'gcc middleend' then make the libraries. Also don't give all the credit to me elfprince is helping on this project like 50/50 with me.
Title: HACC
Post by: bfr on January 24, 2007, 12:52:00 pm
I want to help too...:Ptongue.gif

Oh, OK.   Also, this might help you two:  http://tldp.org/HOWTO/GCC-Frontend-HOWTO.html
Title: HACC
Post by: Halifax on January 24, 2007, 01:04:00 pm
If you want to help you can Ill talk to you on mIRC cause we will need all the help we can get
Title: HACC
Post by: Halifax on January 27, 2007, 06:51:00 am
Update: If you want to die then download GCC compiler source.*cough* 16794 files almost 2000 lines in each*cough*

Update: Anyways the reason I changed from C to TI-83+ to C to z80 processors is because it should be fairly easy to make it compile for 82,83,84,and 86
Title: HACC
Post by: DJ Omnimaga on January 27, 2007, 07:26:00 am
oO wow thats huge
Title: HACC
Post by: elfprince13 on January 27, 2007, 08:36:00 am
its been around a while

and we now have an IRC channel, not much happening now except technical discussion though.

there was an existing project on sourceforge with the same purpose name, that hadn't ever done anything so we've requested administrative control of it, we should hear back within 2.5 weeks.
Title: HACC
Post by: DJ Omnimaga on January 27, 2007, 09:00:00 am
aaah cool, of course i dont mind any calc related discussion in #omnimaga either tho ;)wink.gif
Title: HACC
Post by: Halifax on January 27, 2007, 09:22:00 am
hmm not much is going on in the channel even though the people are on omnimaga site o.oblink.gif Oh well anyways I have a basic understanding of where to start
Title: HACC
Post by: CureDesu on January 27, 2007, 11:27:00 am
Hows the development team coming along? I would love to help, but I don't  know any C or C++ yet.  (Which should I start with? I heard C++ is just a more complex C).  

Anyway, if this project is finished, you'll get many cookies from me.  -.-blah.gif-.-blah.gif
Title: HACC
Post by: JincS on January 27, 2007, 12:35:00 pm
C++ = C + Classes (and a few other minor things)

Actually, C++ is called that because the "++" is the symbol for increment, so C++ is really "C+1" (Or C version 2, whatever).

If you learn C, then you learn C. But if you learn C++, you know both.
Title: HACC
Post by: Halifax on March 12, 2007, 02:22:00 pm
Ok the list has shortened to JincS and I(Halifax). This week coming JincS and I will begin to port ld-tigcc(the linker) onto a68K(the assembler) and then to z80gcc(the actual cross compiler).
Title: HACC
Post by: JincS on March 12, 2007, 06:50:00 pm
Yay! I'm [pretty much] ready!

Nobody else is interested in this project?
Title: HACC
Post by: Halifax on March 13, 2007, 09:33:00 am
Ok JincS and no not many people want to take on this massive dragon of a project lol :)smile.gif Anyways yay I am ready to start to but before we do I have to iron out some details with you to keep things running smooth.(Halifax is glad you are sticking with him)
Title: HACC
Post by: Liazon on March 13, 2007, 10:34:00 am
nice  progress is good  interest will probably increase later for sure though.
Title: HACC
Post by: Halifax on March 13, 2007, 03:44:00 pm
Ok this insanely time-saving and ingenious idea goes to Kevin_Kofler. There is no need to port a68K!!!! Binutils 2.17 already has a target for z80. So all we need to do is get ld-z80gcc to eat all the results and output a TI executable and then write the backend for GCC(the big son of a bit**)
Title: HACC
Post by: bfr on March 13, 2007, 04:16:00 pm
Excellent progress!

I'd still be glad to help (mainly with making an IDE and online documentation - I don't really know much about making compilers, although I may be able to help a small bit with the actual compiler).

If you and JincS manage to finish the compiler, I will be just incredibly astoundingly amazingly happy (and would definitely cheer me up in times of great stress).  
Title: HACC
Post by: JincS on March 13, 2007, 07:11:00 pm
So no a68K then? :(sad.gif Oh well...

I'll email you the condensed source for it, in case you want it anyways. It compiles just fine with Code::Blocks IDE.
Title: HACC
Post by: bfr on March 14, 2007, 11:07:00 am
I can also help out with the library, btw.  
Title: HACC
Post by: Halifax on March 14, 2007, 03:31:00 pm
JincS: Its good that we don't need to port it. It was too 68K specific and also wouldn't have taken some of our time we can now dedicate to writing the backend. Oh yeah and bfr Kevin and I pretty much have the IDE covered.
Title: HACC
Post by: bfr on March 14, 2007, 03:37:00 pm
OK.  Then I guess I can work on the library and the online documentation and work on other stuff as needed.

But, who's Kevin?  DJ Omnimaga knows C++?  Or is JincS's name "Kevin?"

Also, could you two try to make it so that Z8-GCC/the IDE supports/has:

- Raw assembly (maybe it could have integration with SPASM?)
- Inline assembly
- Integration with PindurTI or another emulator
- Flash Applications
Title: HACC
Post by: JincS on March 14, 2007, 08:25:00 pm
I think we should be able to work those in, but it may take a release or two to get to.

I know that one of my priorities it to write this software so that it could be easily ported to a CGI script, so people could compile their z8-GCC programs online.
Title: HACC
Post by: Halifax on March 15, 2007, 07:10:00 am
Ok when I saw Kevin I mean Kevin Kofler. And also doesn't GCC support inline assembly. Remember whatever GCC can compile it will compile and we are just translating it to another system specification. Another thing is. Flash Applications would be fairly hard to integrate since that would require no SMC and multiple pages. And also their are problems with memory locations and others of the sort. Anyways z80 isn't that hard to write ;)wink.gif its easy to make an application and if you expect to make your C programs faster than you are going to have to code some speed-intensive parts in z80 asm.
Title: HACC
Post by: bfr on March 15, 2007, 08:35:00 am
TIGCC supports inline assembly.

"Anyways z80 isn't that hard to write" -> Please tell me you didn't mean that - with that attitude, why are you making this compiler? ;)wink.gif  Making Flash Applications isn't really easier than making regular assembly programs.
Title: HACC
Post by: JincS on March 15, 2007, 08:48:00 am
I think we can program an optional library that will allow for the easy cretion of flash apps. Something that works around memory issues.

Question: what's SMC? Sub-machine code? (Don't forget, I'm not a calc progammer :)smile.gif )

I'm going to put together a template that can be used for coding thge libraries that will make everything consistant and easy-to-use. I'll post it when I get it completed.
Title: HACC
Post by: Liazon on March 15, 2007, 10:52:00 am
SMC = self modifying code
Title: HACC
Post by: JincS on March 15, 2007, 01:28:00 pm
Aaaahhhh... OK. I think we could do a workaround for that.
Title: HACC
Post by: Jon on March 15, 2007, 03:14:00 pm
The two main problems with making flash apps are:
1) Flash can't be written to, eliminating the possibility of SMC.
2) Apps originate from $4000, whereas programs originate from $9d93.  Further complicating this matter is that apps are run from bank A, ($400-$7FFF), whereas programs are run from bank B, ($800-$BFFF).  The problem that arises with this is that the tios's bcalls are on various flash pages, and it swaps out bank A to access them.  So any bcall that reads data from your app (such as a _vputs bcall) will not read the proper data, but will instead read the data at the correct address, but the wrong flash page. :(sad.gif
Title: HACC
Post by: Halifax on March 15, 2007, 03:39:00 pm
exactly Jon understands the severity of this and how hard it would to implement. A workaround is not substantial. And yes if you are a serious z80 programmer then Flash Applications are a breeze. Also how is z80 hard at all. This compiler is being written to make things faster, not necessarily easier because in my eyes ASM is easier than BASIC by far. One line corresponds to one command whereas is basic one line can have many functions being presented. And JincS what do you mean template?
Title: HACC
Post by: JincS on March 15, 2007, 03:50:00 pm
A template, as in a standardized layout which will allow for the consistency of the programming libraries, making for an easier learning curve and faster rapid application development.

Basically, just a way to make things easier for everybody :)smile.gif

**BTW News Update (for those who care)**
The source code to LD-GCC has been condensed and successfully compiled using Code::Blocks IDE. Halifax and I are in the process of deciding on the next step to take. As I won't be in town over the weekend, await a news update from Halifax concerning the next steps of the project.

See everyone on Monday :)smile.gif
Title: HACC
Post by: bfr on March 15, 2007, 04:45:00 pm
Good progress. :)smile.gif

But Halifax, Jon's problems just seem to be problems with making Flash Applications in general.  They don't seem to be reasons why there couldn't be a template for creating Flash Applications or somehting like that.  I may be mistaken, though.
Title: HACC
Post by: JincS on March 15, 2007, 10:26:00 pm
Once we get a stable release with a basic library set up, we'll see what we can do. It should only be a matter of adding some application-defined parameters to the libraries to make it work right. But we'll see...
Title: HACC
Post by: Halifax on March 16, 2007, 12:55:00 am
Ok take it like this. The only way we could get GCC to compile something for Flash capability is to rewrite the GCC compiler which isn't going to happen. The second is to study all of GCC and write a series of patches because GCC builds assembly with SMC. So adding flash capability would be severely hard ok ;)wink.gif.

One thing you could do though is maybe write an ASM converter that converts the ASM to flash capable. That's pretty hard though too.
Title: HACC
Post by: bfr on March 16, 2007, 11:11:00 am
OK.  Sorry if I was being annoying, but I just wanted to know why we couldn't make Flash Applications with it, which I wouldn't think would be too difficult.  Also, I know I've been asking a lot of questions lately (sorry, I know I'm probably getting annoying), but I'm still curious - why would you have to rewrite the GCC compiler?  
Title: HACC
Post by: Halifax on March 16, 2007, 03:15:00 pm
Ok. I will try to explain it so you understand this. GCC is basically built for computers right. And computers support SMC right. Ok then GCC was never meant to compile non-SMC code. That is why it would require a rewrite.
Title: HACC
Post by: bfr on March 16, 2007, 03:55:00 pm
But that doesn't seem to make sense.  It can compile SMC code, but can't compile non-SMC code?  How is that even possible?  Does it run through the code, checking to make sure it has some SMC code, and if it doesn't contain any SMC code, it doesn't work?  :Ptongue.gif

(Sorry if I'm being annoying, but this just doesn't seem to make sense)  
Title: HACC
Post by: Halifax on March 16, 2007, 04:06:00 pm
It makes what it seems is the most optimizable way to compile the program.
Title: HACC
Post by: Jon on March 16, 2007, 04:53:00 pm
Meh, you could add a patch that makes GCC add the code to make an appvar, then mess with the pointers so that SMC is placed within the appvar.
Title: HACC
Post by: Liazon on March 17, 2007, 06:54:00 am
QuoteBegin-bfr+16 Mar, 2007, 20:55-->
QUOTE (bfr @ 16 Mar, 2007, 20:55)
But that doesn't seem to make sense.  It can compile SMC code, but can't compile non-SMC code?  How is that even possible?  Does it run through the code, checking to make sure it has some SMC code, and if it doesn't contain any SMC code, it doesn't work?  :Ptongue.gif

(Sorry if I'm being annoying, but this just doesn't seem to make sense)  

 Keep in mind that GCC was designed to compile computer programs.  I don't know much about computers, but I'd guess that a lot of file I/O involves copying to RAM, since the bus? between HDD and processor would be really slow compared to processor and RAM.  Thus, SMC (as in "variables" within the code that get modified, though I guess SMC executable is a possibility too) would be ideal, otherwise all variables have to be malloc'd in RAM or something
Title: HACC
Post by: Halifax on March 17, 2007, 12:05:00 pm
Yes Liazon exactly, but for some of you I don't think you are getting an idea of how big GCC really is. So to write a patch for GCC you have to know what it is doing and when it is doing it and why. To write a backend all you need to do is take what GCC spits out. Patches are not ideal to the process and I think you guys should really just forget Applications.
Title: HACC
Post by: bfr on March 17, 2007, 03:14:00 pm
OK.  After talking more with Halifax and Kevin Kofler, I see why it would be hard to allow Z8-GCC to be used to create Flash Applications.

But is inline assembly and integration with raw assembly (for the IDE) still possible?
Title: HACC
Post by: Halifax on March 17, 2007, 04:27:00 pm
As I have said before. Whatever GCC supports natively will be supported by z8-GCC. Which means inline assembly. And can you elaborate on what you mean by raw assembly.
Title: HACC
Post by: bfr on March 17, 2007, 04:41:00 pm
Raw assembly, pure assembly, plain good old assembly.  Like this:

or a
ret z

I don't mean hexidecimal or anything like that, though.  
Title: HACC
Post by: Jon on March 17, 2007, 05:24:00 pm
I think writing your own custom code that executes after GCC does its thing could work.  Just have it look at all the variables used in the original .C file, and rewrite the pointers in the .ASM file that GCC created.
Title: HACC
Post by: Halifax on March 17, 2007, 05:56:00 pm
oh bfr that's basically the same as inline assembly. And no Jon. For that you would have to write your on parser. As I have said before forget the applications. Its a feat even to get GCC to work with z80.
Title: HACC
Post by: Delnar_Ersike on July 31, 2007, 11:02:00 pm
Me wants progress on this project for specific... reasons... :rainbowdevil:rainbowdevil.gif
Title: HACC
Post by: DJ Omnimaga on August 01, 2007, 01:58:00 am
He seems on vacation, I hardly see him on anymore x.x
Title: HACC
Post by: Goplat on August 01, 2007, 12:28:00 pm
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.
Title: HACC
Post by: DJ Omnimaga on August 01, 2007, 12:29:00 pm
I see, this means we are stuck with BASIC and ASM then, right?
Title: HACC
Post by: Goplat on August 01, 2007, 12:54:00 pm
If you don't want programs that take up more space than they have to, that's probably a good idea.
Title: HACC
Post by: DJ Omnimaga on August 01, 2007, 01:03:00 pm
Well, BASIC is huge, and slow, but if it's gonna take more space with C its better to stay with BASIC or asm. And BASIC is pretty nice for creating RPGs and if you're good other types of games as well. Then if you want speed and even smaller size assembly solve the issue, altough it's much harder to startup with
Title: HACC
Post by: Halifax on August 01, 2007, 04:31:00 pm
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.
Title: HACC
Post by: Halifax on August 31, 2007, 01:26:00 pm
Alright well I kind of have 2 updates. One doesn't matter and another is a major advancement.

First announcement: The name of the compiler is now HACC(Halfiax's C Compiler). Haha I am so original ;)wink.gif . The name isn't final though exactly.

Second announcement: The major advancement that is one of the key driving forces behind parsing C code, and the technology behind all the internal data types in HACC is nearing the end of the development process. Generic Trees are finally shaping up. Some key things of what it can do now.

* Build a full tree containing any number of nodes that can be contained in memory
* Inserting triplets right into a leaf node
* Deleting triplets right from a branch node
* Obtaining triplets from any place in the tree
* Resolving triplets through a callback built by the programmer

Things to implement:

* Any number of child members to one parent
* Resolving variable child members
* Recursive resolving of the tree from custom resolution callback list

After the things to implement are implemented, then we can begin to build the trees needed on top of that.

Just for fun I recorded a quick little debug session of a small small tree :Ptongue.gif

c1-->
CODE
ec1
Tree created successfully
 
Title: HACC
Post by: DJ Omnimaga on August 31, 2007, 01:40:00 pm
THis is awesome to see this revived, I noticed the new name as well in the title. I can't wait to make a game using this :Dbiggrin.gif, will they require a shell like mirage or ion to run? And what are "node"s?
Title: HACC
Post by: Ranman on August 31, 2007, 02:01:00 pm
If you define some rules and/or limitations (something like Small C), then your C compiler implementation complexity will decrease substantially. ;)wink.gif

Now... what are those darned rules/limitations? :gah:fou.gif
Title: HACC
Post by: Halifax on August 31, 2007, 02:32:00 pm
Nah I don't think I am going to take out anything really from the C language, except maybe from the preprocessor. I mean with three developers working on this, things are starting to go smoothly at least. :)smile.gif

And also this project was never really dead. We have been working on it all along.

Also DJ_Omnimaga a node is a piece of a tree. It is just technical jargon that is used to describe trees.
Title: HACC
Post by: Ranman on August 31, 2007, 02:46:00 pm
QuoteBegin-Halifax+31 Aug, 2007, 20:32-->
QUOTE (Halifax @ 31 Aug, 2007, 20:32)
Nah I don't think I am going to take out anything really from the C language, except maybe from the preprocessor.

Actually, I was thinking about limiting things for the Z80 implementation such as:

- floats & double floats
- variable number of arguments (ex. printf() )
- possibly consider leaving out 32 bit integers
Title: HACC
Post by: Halifax on August 31, 2007, 02:51:00 pm
Hmm you know I was considering leaving out 32 bit integer, but I thought it would be so fun to see what people come up with even though they are slow. Sigma made a whole slew of 32 bit manipulation routines so I was going to just throw them in there.

Oh, but yes, that is one thing I was tossing around. I think I am just going to leave floats out for now, personally because I doubt people would use them and they are just too much to manage.

Oh yeah and variable arguments are allowed up until 16 arguments which is only 64 bytes at most on the stack. I really have never seen anything over 16, but it will report an error when a variable argument recieves anything above 16 arguments.
Title: HACC
Post by: Ranman on August 31, 2007, 03:07:00 pm
You could also leave out the following C commands:

- do/while (redundant with 'for' loops)
- switch/case (redundant with 'if/else')
- goto (bad programming practice)


The following C types are not absolutely necessary either:

- register (you probably don't have enough registers to spare)
- auto (I have never even seen this used)
- union
- const
- and bitfields (redundant with shifting & masking)
Title: HACC
Post by: Halifax on August 31, 2007, 03:16:00 pm
Woah woah, now you are talking about killing the face of C, and breaking a bunch of source trees. I agree with getting rid of auto. I agree with taking away bitfields. I don't agree with taking away do/while switch/case or goto. Goto can give you serious optimizations.

E.G.

case 1:
... do something ...
store to huge struct
case 2:
... do something else ...
store to huge struct

can be optimized to

case 1:
... do something ...
goto store
case 2:
... do something ...
store:

That saves a bunch of memory, because I guarantee you that HACC won't be looking to optimize that, nor does GCC I think.

Also I am keeping register because it can make a difference if the register is taken, which will be kept track of.

And 'const' does affect what happens. 'char' is stored in RAM while a 'const' is stored in the program since it is always constant.

Yeah I think I am going to take unions out. I agree with that.
Title: HACC
Post by: Ranman on August 31, 2007, 03:31:00 pm
QuoteBegin-Halifax+31 Aug, 2007, 21:16-->
QUOTE (Halifax @ 31 Aug, 2007, 21:16)
Woah woah, now you are talking about killing the face of C, and breaking a bunch of source trees.

Okay... I agree with you on 'const'. :Ptongue.gif But, a compiler could be designed to treat program constants as "implied" constants.

I agree with your point on 'goto' as well, but then you will have to implement labels -- which is something else that could be left out. :Ptongue.gif

But I'm not killing the face of C... because I prefaced my statements by saying you could implement a "Small C" -- suggesting a subset of C. Removing everything I stated will still compile with a standard C compiler -- while reducing complexity of the compiler. ;)wink.gif


These are just suggestions... take them for what they are worth. :)smile.gif


I always thought it would be cool to have a complete programming language as minimal as possible. C is pretty close to that, but it still has a few redundant and unnecessary things. :)smile.gif
Title: HACC
Post by: Halifax on August 31, 2007, 04:17:00 pm
Well labels aren't hard. They are arbituary. They translate directly into assembly. E.g.

... C code
goto A
... C code
A:

translates to

... translated C code
jp LA
... translated C code
LA:

I like your suggestions though. Keep them coming!
Title: HACC
Post by: JincS on August 31, 2007, 08:11:00 pm
Halifax: Any support for namespaces? Namespaces + structures + functions = possibility for OOP using ANSI C...

BTW, The assembler hasn't been worked on since the beginning of July->I got that roofing job, so I've been working 6-70 hours a week (6 days a week, which is why I really haven't been active all summer :(sad.gif ). I'm hoping to find some time to finish/optimize it sometime soon, but I really can't say when it'll get done.

Xlibman: A node is like a leaf on a tree->it's at the end of a tree branch :)smile.gif

**EDIT**

Halifax: Which algorithm are you using for your tree sorting/searching? I haven't seen your source in quite some time...*hinthintwinkpokenudge*
Title: HACC
Post by: DJ Omnimaga on September 01, 2007, 02:34:00 am
aaah i see jincs, thanks :)smile.gif
Title: HACC
Post by: Halifax on September 01, 2007, 08:08:00 am
JincS: Corrention: A node is a leaf or branch. I node is a very ambiguous word kind of like int. There is a 'short int' and 'long int' just as there is a 'branch node' and 'leaf node' with a tree. Once I get timing implemented into my tree I am going to post a more complicated example with a given tree and simplifying.

Also JincS you haven't seen the code since you only stop by the channel for 1 minute at the most and then leave ;)wink.gif. I am there almost everytime you do that, but I am working on HACC which takes up the full screen. If you message me it will make a sound and then I will know your there.

And to answer your other question. The generic trees are built specifically to be generic to Hacc not generic trees in general lol. That means that there is no sorting or searching that needs to be done. They are built by the parser and are simplified by the parser. The generic routines provide at least a minimal gateway to manipulate these trees very easily.

Secondly no namespaces will be allowed.

And yeah we are building an assembler anymore. We are going to use a very customized SPASM, although we still have to build the linker.
Title: HACC
Post by: DJ Omnimaga on September 01, 2007, 12:05:00 pm
i think jincs should stay in the channels and just change his nick to Jincs|away when he's idle, because most of the time I saw him leave he was still connected to the network, just not any channels
Title: HACC
Post by: Halifax on September 02, 2007, 02:06:00 pm
@Ranman: I have been reading up on unions, since I never really use them since I thought they were useless like you. But I never realized that they could actually seriously help with memory addressing. E.g.

union {
    ui16 word[4];
    ui32 dword[2];
    i64 qword;
} 64_bit_location;

I don't know I am considering keeping unions in, unless there is a way that you can do that some other way?
Title: HACC
Post by: Ranman on September 02, 2007, 03:27:00 pm
QuoteBegin-Halifax+2 Sep, 2007, 20:06-->
QUOTE (Halifax @ 2 Sep, 2007, 20:06)
@Ranman: I have been reading up on unions, since I never really use them since I thought they were useless like you.

Well... I never said unions were "useless". I just don't think they are absolutely necessary.

QuoteBegin-Halifax+2 Sep, 2007, 20:06
-->
QUOTE (Halifax @ 2 Sep, 2007, 20:06)
But I never realized that they could actually seriously help with memory addressing. E.g.

union {
Title: HACC
Post by: Halifax on September 02, 2007, 09:28:00 pm
But then you can't access the data as both bytes, words, and longwords etc. You can only access it is that certain type.
Title: HACC
Post by: Ranman on September 03, 2007, 01:17:00 am
QuoteBegin-Halifax+3 Sep, 2007, 3:28-->
QUOTE (Halifax @ 3 Sep, 2007, 3:28)
But then you can't access the data as both bytes, words, and longwords etc. You can only access it is that certain type.  

 Sure you can...

Pointers and/or typecasting.
Shifting and/or masking.


But... How many actual programs are going to access data as bytes, words, and longwords at the same time? In my opinion, very few if any.

My point is... you are designing and implementing a compiler for a VERY limited system. You don't need all of the bells and whistles. Focus on the things that are absolutely necessary and make them small, fast, and efficient as possible. You can always add the icing later. ;)wink.gif
Title: HACC
Post by: DJ Omnimaga on September 03, 2007, 05:05:00 am
@Ranman: providing you arent too much limited when coding either though ;)wink.gif

btw i was wondering if there was some progress in this or if it is still in planning stages?  
Title: HACC
Post by: Halifax on September 03, 2007, 12:28:00 pm
@Ranman: I know what you mean, but the use of unions can lead to serious user optimizations. You can most definitely use unions that way for fixed point arithmetic! That is what I use them for all the time.

@DJ_Omnimaga: I would say some parts are more mature than other parts of Hacc. Our major concern is a fast compiler with greatly substantial optimizing. E.g. Shifts where a ^2 multiplication is used, constant elimination, and dead code elimination. Also register allocation has to be up to par. Right now I am currently defining and planning a special level to the compiler built specifically for optimizing.

Also just in case anyone is wondering, this isn't a once-and-done project. We will strive to keep this maintained, so don't worry if something is missing, or there are some bugs.
Title: HACC
Post by: Ranman on September 03, 2007, 01:09:00 pm
QuoteBegin-Halifax+3 Sep, 2007, 18:28-->
QUOTE (Halifax @ 3 Sep, 2007, 18:28)
@Ranman: I know what you mean, but the use of unions can lead to serious user optimizations. You can most definitely use unions that way for fixed point arithmetic! That is what I use them for all the time.  

 That sounds pretty good.  :)smile.gif
Title: HACC
Post by: DJ Omnimaga on September 03, 2007, 01:46:00 pm
nice deal I guess :)smile.gif, providing the output programs doesn't take twice as much memory than their BASIC or Z88dk counterpart it should all be good :)smile.gif
Title: HACC
Post by: JincS on September 03, 2007, 04:57:00 pm
lol I forgot that you could have branch nodes too :Ptongue.gif I don't use trees all that often :(sad.gif
QUOTE
Also JincS you haven't seen the code since you only stop by the channel for 1 minute at the most and then leave ;)wink.gif. I am there almost everytime you do that, but I am working on HACC which takes up the full screen. If you message me it will make a sound and then I will know your there.


So that's where you're always at...

Ok, so no namespaces and no homebrew assembler...sounds good :)smile.gif I'll look into spasm and see what I can do about a linker then (assuming I can find the time->work's killing me, since I got bumped up to 8-hour weeks :cry: )...
Title: HACC
Post by: Halifax on September 04, 2007, 04:52:00 am
To work on the linker you are going to have to be brought up to speed on a number of different subjects dealing with Hacc. :(sad.gif

@DJ_Omnimaga: I don't even think it is possible to generate an executable as large as z88dk, especially if you keep your command-lines tight! Also you really can't have a BASIC counterpart to C.

Also I just want to say this also to people. Don't get false ideas that you can lay down horrible code and have Hacc output a perfect little piece of code. Steps to get you code looking nice:

1. Provide optimized C source code, and make sure no stupid things are done.
2. Let other people look over your code an optimized it.
3. Do research on which command lines are for you. There is an array of possible command line arguments already available for Hacc, and I can guarantee that more will come!

Let me just give an example of a command line argument that could or could not make a serious impact on the executable speed and size.

--forcejp

If this command line argument is present, then all jr's will be turned into jp's. So that means 1 byte per ever jr turned into a jp, but more speed also. My advice would be.

If you want size, then don't use --forcejp, but if you want speed, then use --forcejp. Now there are some things to take into consideration. For ever 'if' there is a jump, and for ever 'if-else' there is 2 jumps, and so on. So if your program is performing lots of decisions, then I recommend not using --forcejp.

Also if you have a very limited machine with less than 256 or 128 MB of ram or something you can also provide some command line arguments to reduce the amount of memory that is possible for Hacc to use. These are some advanced features though so I wouldn't advise these for any beginners though.

And as a final note. Don't expect perfect code from Hacc. If you are expecting perfect code, then Hacc, and probably any other compiler, isn't for you. Assembly language is the language for you.

EDIT:

I can't believe I forgot one of the main things I wanted to post about. The integration of the z80 assembly language right into the HACCLIB. I got this idea as I was reading an article on CELL programming because this is exactly what STL did to replace the horror of inline-assembly for there SPEs.

E.g.:

z80_rr(&plotsscreen, 1)

is an inline function that translate directly to one command: rr (hl) where hl points to plotsscreen.

So the whole z80 language will be represented in C and many low level assembly routines would be able to be represented in this way. Plus it integrates very well with your C program allowing you to easily program in pseudo assembly.

EDIT2:

Also I don't know if anyone cares, but support for local typedef definitions and local structure definitions will be completely dropped. The reason for this is because it is completely pointless and it just complicates parsing and handling of scopes. Just put the typedef or structure definition outside of any functions and then put a variable declaration in the same place you would put the local typedef or structure. It will generate the same code so don't worry about it.
Title: HACC
Post by: JonimusPrime on September 04, 2007, 05:00:00 am
Wow now I have to go and learn C/C++ I didn't even know this project existed.
Title: HACC
Post by: DJ Omnimaga on September 04, 2007, 05:41:00 am
You've made a pretty nice discovery %)rolleyes2.gif

I am myself waiting for it as well, because maybe this could make porting 83+ games to 89 easier if i ever venture into C again
Title: HACC
Post by: Halifax on September 04, 2007, 06:17:00 am
Yes it most definitely would. Also why do people group C/C++? C++ is an extension of C, and has many distinguishes differences in my mind. If based of extensions then shouldn't it be B/C/C++/D?
Title: HACC
Post by: calc84maniac on September 04, 2007, 06:19:00 am
Just so you know, jr is actually faster than jp on average if there's a 50% chance of jumping... :oohmy.gif
Title: HACC
Post by: DJ Omnimaga on September 04, 2007, 06:21:00 am
well technically the 89t can only have C, right? I don't think C++ is really that necessary
Title: HACC
Post by: Halifax on September 04, 2007, 07:36:00 am
@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.
Title: HACC
Post by: calc84maniac on September 04, 2007, 07:40:00 am
jr average=(7+12)/2=9.5, jp average=(10+10)/2=10. Assuming that there's about a 50% chance that it will do the jump.
Title: HACC
Post by: Halifax on September 04, 2007, 07:45:00 am
If that's how you do probability...either way as I said there is no way in basing the speed of your routine off of this and it would be best just to stick with the constant of jp. If worst comes to worst then just specify -dump-intfiles, optimize it to your liking, and then assemble and link it with the rest of your program.
Title: HACC
Post by: DJ Omnimaga on September 04, 2007, 07:56:00 am
QuoteBegin-Halifax+4 Sep, 2007, 14:36-->
QUOTE (Halifax @ 4 Sep, 2007, 14:36)
@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.  

 yeah i was more talking about the fact there's no compiler that can do it yet, Idk what would be the point to write one tho, because C is alerady good enough and its a calc anyway ;)wink.gif
Title: HACC
Post by: Halifax on September 04, 2007, 08:00:00 am
Hmm yes C is fine which is why I advocate for it, but many people say it is easier to program in C++. Although I must admit that C++ is better for engine development and also GUI development, it is nothing that C can't handle.
Title: HACC
Post by: bfr on September 04, 2007, 11:09:00 am
QuoteBegin-Halifax+4 Sep, 2007, 11:17-->
QUOTE (Halifax @ 4 Sep, 2007, 11:17)
Yes it most definitely would. Also why do people group C/C++? C++ is an extension of C, and has many distinguishes differences in my mind. If based of extensions then shouldn't it be B/C/C++/D?

For the most part, C++ is backwards-compatible with C, and C and C++ seem to be the most common.
Title: HACC
Post by: Liazon on September 04, 2007, 12:08:00 pm
QuoteBegin-Halifax+4 Sep, 2007, 13:45-->
QUOTE (Halifax @ 4 Sep, 2007, 13:45)
If that's how you do probability...either way as I said there is no way in basing the speed of your routine off of this and it would be best just to stick with the constant of jp. If worst comes to worst then just specify -dump-intfiles, optimize it to your liking, and then assemble and link it with the rest of your program.  

 I agree with you.  Sometimes i find just by design, the chance of the jr jumping is less than not jumping by a lot.  when that's the case, I usually use jp.  the space is no big issue for me atm because i'm doing mainly apps.

btw, i think you might as well try to make a java interpreter/compiler for 8x+ instead of C++.  i started learning recently and it's awesome.
Title: HACC
Post by: Halifax on September 04, 2007, 12:34:00 pm
@bfr: D is also backwards compatible with C and C++, and it holds immense popularity already! Mainly because you can link to C and C++ libraries which means OpenGL, DirectX, SDL, Qt, and every other great library is available for D!

*Halifax
Title: HACC
Post by: Liazon on September 05, 2007, 12:09:00 pm
^^ sorry i meant 68k lol.
Title: HACC
Post by: bfr on September 05, 2007, 12:14:00 pm
Halifax:  Hmmm, I'll have to get into more D programming.  Hacc is going to support Flash applications?  That's awesome!  :Dbiggrin.gif
Title: HACC
Post by: Halifax 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.
Title: HACC
Post by: DJ Omnimaga 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.oblink.gif

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
Title: HACC
Post by: darkfire 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.
Title: HACC
Post by: DJ Omnimaga 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 :Ptongue.gif

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

Welcome here darkfire btw. :)smile.gif
Title: HACC
Post by: Halifax 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 ;)wink.gif

Really C does *do* the job...I guess...unless you try to make your own abs() macro. Try it :Ptongue.gif 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. ;)wink.gif

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.
Title: HACC
Post by: calc84maniac 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.
Title: HACC
Post by: Halifax 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.
Title: HACC
Post by: calc84maniac 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... @[email protected] oh well, here.
Title: HACC
Post by: Halifax 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. ;)wink.gif 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. :)smile.gif 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.oblink.gif
Title: HACC
Post by: bfr on September 06, 2007, 03:55:00 pm
Halifax, what do you mean by "rotations?"
Title: HACC
Post by: DJ Omnimaga on September 06, 2007, 06:06:00 pm
Moved to the new HACC forum!
Title: HACC
Post by: calc84maniac on September 07, 2007, 09:55:00 am
I believe he means "RRC/RLC/RR/RL" rotations.
Title: HACC
Post by: Halifax 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.
Title: HACC
Post by: Liazon 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) :)smile.gif
Title: HACC
Post by: Delnar_Ersike on September 08, 2007, 06:37:00 am
Kind of off-topic note: shouldn't this be moved to the Halifax's Projects subforum?
Title: HACC
Post by: DJ Omnimaga on September 08, 2007, 10:23:00 am
it did o.oblink.gif it's in HACC sub forum o"O
Title: HACC
Post by: Delnar_Ersike on September 08, 2007, 05:07:00 pm
QuoteBegin-DJ Omnimaga+8 Sep, 2007, 14:23-->
QUOTE (DJ Omnimaga @ 8 Sep, 2007, 14:23)
it did o.oblink.gif it's in HACC sub forum o"O  

user posted image
Title: HACC
Post by: DJ Omnimaga on September 08, 2007, 05:42:00 pm
Look below Ultima V forum <_<dry.gif Considering its a large project I felt it would need its own forum like pokemon and ultima
Title: HACC
Post by: JonimusPrime on September 08, 2007, 06:56:00 pm
I agree with DJ on this one.
Title: HACC
Post by: DJ Omnimaga on September 09, 2007, 12:19:00 am
He prbly didn't noticed the HACC forum yet. Most people use Today Active Topics, and HACC need to be moved up in alphabetical order anyway
Title: HACC
Post by: Delnar_Ersike on September 09, 2007, 06:00:00 am
Nah, I actually look at the forums alphabetically and have seen the HACC subforum: it's just that it feels weird to me that the project itself has its own subforum, despite the fact the author already has a subforum dedicated to him (kind of like there was a member called "HACC" %)rolleyes2.gif ).
Title: HACC
Post by: DJ Omnimaga on September 09, 2007, 09:37:00 am
Well, if you look throughly, most huge projects have their own sub forums anyway, i did this to grab people attention more. For example, they see the name Pokemon, so they go immediately check because it's pokemon, things like that
Title: HACC
Post by: DJ Omnimaga on September 09, 2007, 01:27:00 pm
double post: I've reordered project forums so its in alphabetical order now. Back on topic now :)smile.gif
Title: HACC
Post by: DJ Omnimaga on September 18, 2007, 06:59:00 am
QUestion: I was re-reading through the entire thread and saw HACC will not be able to make flash app. Will it allow you to have sub program running or stuff like this, and allow to copy the content of an archived program to ram? That way it would be a work around the 24 KB limit, which will be easily reached with an RPG or a game with several maps. It's still ok if it doesn't support this though, I was just wondering
Title: HACC
Post by: Halifax on September 18, 2007, 08:56:00 am
HACC progress through stages, and the things said earlier aren't exactly true. It will be able to produce a Flash App, and also the limit is 8KB. You can get around the 8KB limit by making external files and other things, or using shared libraries, or you can build an application/
Title: HACC
Post by: bfr on September 18, 2007, 11:13:00 am
The limit for regular (not Flash Applications) assembly programs is 8k?  Castlevania, for example, is way over 8k.  Or is this only allowed because it's a MirageOS program?
Title: HACC
Post by: JonimusPrime on September 18, 2007, 03:31:00 pm
8k is the limit of runnable code the rest has to be data or you have to make a workaround to run it.
Title: HACC
Post by: DJ Omnimaga on September 18, 2007, 03:41:00 pm
QuoteBegin-Halifax+18 Sep, 2007, 15:56-->
QUOTE (Halifax @ 18 Sep, 2007, 15:56)
HACC progress through stages, and the things said earlier aren't exactly true. It will be able to produce a Flash App, and also the limit is 8KB. You can get around the 8KB limit by making external files and other things, or using shared libraries, or you can build an application/  

 YAY! Good to see you readded it, i didnt knew since there was several months without progress posted at one point x.x

*DJ Omnimaga
Title: HACC
Post by: Delnar_Ersike on September 19, 2007, 04:25:00 am
QuoteBegin-DJ Omnimaga+18 Sep, 2007, 19:41-->
QUOTE (DJ Omnimaga @ 18 Sep, 2007, 19:41)
*DJ Omnimaga
Title: HACC
Post by: DJ Omnimaga on September 19, 2007, 05:02:00 am
its 8 KB for the executable code, not the on calc program
Title: HACC
Post by: Halifax on September 19, 2007, 02:38:00 pm
No the thing is. TI doesn't want to support game programming directly they make Assembly available, but with an 8 KB limit. This means that no one assembly program that is over 8 KB can be run with Asm().

Yes the workaround is MOS(and others), which perform the highly standard algorithm(now) of ram swapping which allows for those huge games like gemini and stuff.

The other workaround is to just put all the code you can in 8 KB, and once you run out you can put graphics in external files, and maybe even make a DLL or two to hold some code, or turn to applications(as a last resort).

Now of course HACC will only support the latter because it is senseless to try the former. Adding support for Ion, MOS, Crunchy, DCS, and whatever shells come on down the road is hard work to build directly into the linker. So what needs to be done to get support for shells? Make your own C "API" to access the Assembly "API" of these shells, and distribute them.

EDIT:

Update: I am working out hash tables right now. Updates down the road on how this works out later. And also maybe some documents of my notes on compilation to get some input.

Only thing that sucks is MinGW is broken for some odd reason.  :gah:fou.gif
Title: HACC
Post by: DJ Omnimaga on September 19, 2007, 02:59:00 pm
glsd to see more updates :)smile.gif thanks for clarifying about the 8 KB limit :)smile.gif
Title: HACC
Post by: calc84maniac on December 20, 2007, 09:55:00 pm
*returns to Omnimaga*

*bumps topic*

*wonders about progress*

*slinks away*
Title: HACC
Post by: DJ Omnimaga on December 21, 2007, 01:02:00 am
wow it hasbeen a while since you last posted here (and your very own forum <_<dry.gif), nice to see you again :)smile.gif

Unfortunately I think HACC is dead because the guy ditched calcs altough his interest sparkled again when Lost Legends got announced so he starting helping out this RPG with Liazon
Title: HACC
Post by: JincS on December 21, 2007, 08:50:00 am
If I had Halifax's source for what he's done so far, I'd continue it. *hinthint*
Title: HACC
Post by: Liazon on December 21, 2007, 06:33:00 pm
this would have been nice though :)smile.gif