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.
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.
I want to help too...:P
Oh, OK. Also, this might help you two: http://tldp.org/HOWTO/GCC-Frontend-HOWTO.html
If you want to help you can Ill talk to you on mIRC cause we will need all the help we can get
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
oO wow thats huge
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.
aaah cool, of course i dont mind any calc related discussion in #omnimaga either tho ;)
hmm not much is going on in the channel even though the people are on omnimaga site o.o Oh well anyways I have a basic understanding of where to start
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. -.- -.-
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.
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).
Yay! I'm [pretty much] ready!
Nobody else is interested in this project?
Ok JincS and no not many people want to take on this massive dragon of a project lol :) 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)
nice progress is good interest will probably increase later for sure though.
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**)
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).
So no a68K then? :( 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.
I can also help out with the library, btw.
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.
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
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.
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 ;) 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.
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? ;) Making Flash Applications isn't really easier than making regular assembly programs.
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 :) )
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.
SMC = self modifying code
Aaaahhhh... OK. I think we could do a workaround for that.
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. :(
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?
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 :)
**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 :)
Good progress. :)
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.
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...
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 ;).
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.
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?
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.
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? :P
(Sorry if I'm being annoying, but this just doesn't seem to make sense)
It makes what it seems is the most optimizable way to compile the program.
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.
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? :P
(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
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.
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?
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.
Raw assembly, pure assembly, plain good old assembly. Like this:
or a
ret z
I don't mean hexidecimal or anything like that, though.
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.
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.
Me wants progress on this project for specific... reasons... :rainbowdevil:
He seems on vacation, I hardly see him on anymore x.x
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.
I see, this means we are stuck with BASIC and ASM then, right?
If you don't want programs that take up more space than they have to, that's probably a good idea.
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
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.
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 ;) . 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 :P
c1-->| CODE | ec1
Tree created successfully
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 :D , will they require a shell like mirage or ion to run? And what are "node"s?
If you define some rules and/or limitations (something like Small C), then your C compiler implementation complexity will decrease substantially. ;)
Now... what are those darned rules/limitations? :gah:
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. :)
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.
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
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.
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)
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.
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'. :P 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. :P 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. ;) These are just suggestions... take them for what they are worth. :) 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. :)
... 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!
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 :( ). 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 :)
**EDIT**
Halifax: Which algorithm are you using for your tree sorting/searching? I haven't seen your source in quite some time...*hinthintwinkpokenudge*
aaah i see jincs, thanks :)
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 ;). 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.
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
@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?
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 {
But then you can't access the data as both bytes, words, and longwords etc. You can only access it is that certain type.
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. ;)
@Ranman: providing you arent too much limited when coding either though ;)
btw i was wondering if there was some progress in this or if it is still in planning stages?
@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.
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. :)
nice deal I guess :), providing the output programs doesn't take twice as much memory than their BASIC or Z88dk counterpart it should all be good :)
lol I forgot that you could have branch nodes too :P I don't use trees all that often :(
| 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 ;). 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 :) 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: )...
@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.
Wow now I have to go and learn C/C++ I didn't even know this project existed.
You've made a pretty nice discovery %)
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
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?
Just so you know, jr is actually faster than jp on average if there's a 50% chance of jumping... :o
well technically the 89t can only have C, right? I don't think C++ is really that necessary
@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.
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.
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.
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 ;)
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.
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.
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.
@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
^^ sorry i meant 68k lol.
Halifax: Hmmm, I'll have to get into more D programming. Hacc is going to support Flash applications? That's awesome! :D
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.
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
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.
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 :P
As I said if C do the job, I guess there isn't much need for C++ anyway.
Welcome here darkfire btw. :)
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 :P 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.
Signed comparison is cinchy... Just compare the first number to [the second number with top bit inverted] and check p/v.
calc84maniac: Ummm...what? Dude I am talking about implementing it as a macro for compilers, not assembly.
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.
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 | QUOTE (DJ Omnimaga @ 8 Sep, 2007, 14:23) | | it did o.o it's in HACC sub forum o"O |
Look below Ultima V forum <_< Considering its a large project I felt it would need its own forum like pokemon and ultima
I agree with DJ on this one.
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
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" %) ).
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
double post: I've reordered project forums so its in alphabetical order now. Back on topic now :)
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
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/
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?
8k is the limit of runnable code the rest has to be data or you have to make a workaround to run it.
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
QuoteBegin-DJ Omnimaga+18 Sep, 2007, 19:41-->| QUOTE (DJ Omnimaga @ 18 Sep, 2007, 19:41) | *DJ Omnimaga
its 8 KB for the executable code, not the on calc program
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:
glsd to see more updates :) thanks for clarifying about the 8 KB limit :)
*returns to Omnimaga*
*bumps topic*
*wonders about progress*
*slinks away*
wow it hasbeen a while since you last posted here (and your very own forum <_<), nice to see you again :)
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
If I had Halifax's source for what he's done so far, I'd continue it. *hinthint*
this would have been nice though :)
|
|
|
|
:evil: