lol and w00t 3rd place!

*Halifax

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.

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.

@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.

Alright spengo I would definitely like to test on your system. Is that alright? No programs will crash you system, trust me.

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.

@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.

But then you can't access the data as both bytes, words, and longwords etc. You can only access it is that certain type.