HuC Questions - Implicit Casting (char to int)

[Hu-man]

Hey folks!

I've been fooling around with HuC and have been attempting to squeeze my code into the 256KB system 3 card limit to test on real hardware. I figured that converting my variables from int (16-bit signed) to char (8-bit unsigned) would save some space, since all of the documentation I've read suggests that. However, my compiled code is now actually 30KB larger than before.

I'd assume that HuC implicitly casts a char to int and vice versa when a function requires that datatype, but does it also cast for other operations? For example, I believe it does when incrementing (i.e. char++) and when using a char as an array index (i.e. x[char]). Is there a list of operations where HuC will cast the variables to int? I could do a lot of testing to figure it out, but I don't really want to reinvent the wheel if I can avoid it.

For those of you who know Assembly, here's another question. Keep in mind that I have absolutely no assembly experience, so be gentle.

In the assembly code generated by HuC, I've noticed that incrementing a char variable requires 2 operations (__addwi 1 and stx) whereas an int only requires 1 (incw). Are these 2 operations (and their 8-bit counterpart operations) still faster than incw? Do they take less space? I'm assuming that just because the generated assembly is smaller doesn't mean that it's faster/uses less memory.

Also, it seems that when doing an operation like multiplying a char, _ldwi and _pushw are being used. Am I correct in assuming that the "w" is for "word" and these are the 16-bit operations being used for the 8-bit char? Does this have any negative effect?

As it is, I'm really not seeing any advantage to using char instead of int. Am I missing something?

[TheOldMan]

I'd assume that HuC implicitly casts a char to int ...

So far as I can tell, HuC does not cast either way. What you declare is what you get.
And changing variable sizes won't solve the problem you are having. All variables live in one 8K page.

incrementing a char variable requires 2 operations....

No. Those 'operations' are macros. To get an accurate idea of the operations, you need to look at what the macros consist of. Are you looking in the .lst file? That usually prints the unrolled the macros for you after they are used.

when doing an operation like multiplying a char, _ldwi and _pushw are being used

Multiplication is a subroutine; the processor lacks a hardware multiply operation.
I believe it is calling a generic routine, which needs to handle 16-bit numbers, so it uses the 16 bit macros.
I may be wrong about that, though. It may be doing things via addreses...

As it is, I'm really not seeing any advantage to using char instead of int. Am I missing something?

Quite a lot actually. This is an old 8-bit processor. Things modern processors do easily have to be done via software. Huc doesn't do a good job of optimizing, nor is it especially good at tracking variable types.
(It's up to you to do that.) It also does a poor job of array access.
But it's what we have to work with.
...................................................................

Now, to answer your original question.... Your problem is that your functions are too large. The assembler does a fair job of allocating space to functions, -if- they are small. It is quite easy in HuC to create a function in C that generates more than 8K of machine code. Once that happens, the assembler will allocate a second 8K page for the rest of the code. Unfortunately, the rest of that page will be unused, leaving large chunks of unsused space.

By using smaller functions, they can be packed into the pages better (since the assembler no longer has to treat 2 pages as one large block). Both TheOldRover and I have run into this phenomenon, and found that splitting up large functions and/or rearranging their order in the files can provide significant space savings.

[Hu-man]

Thanks for the help!

I didn't know that about the function size. I'll break them up!

I guess I was thrown off by the fact that my compiled code grew 30KB just by changing to a smaller datatypes. Implicit casting was the only thing I could think of that could have caused the big jump in size.

[Arkhan]

Must be something to do with people that have "TheOld" in their name.    ...that, or I just get lucky with Atlantean. 

... so far at least.


A good way to optimize your function space use is you can look at the listing and see how large the function is by looking at the start/end addresses.

Shrink where you can, relocate stuff as well.  If you go just one little teeny tiny bit over, you now have an ENTIRE new page just for that one little bit.   It sucks.

My rule of thumb for variable use:

Use ints if you're going to be passing it into any functions that take ints.   Use chars if you know you can (I use them for things that never exceed 255, and never actually get passed into any library functions).   If you think about what you'll be doing with the variable, you can usually decide what type it should be.

Also, use #defines when you can.

[nodtveidt]

Now, to answer your original question.... Your problem is that your functions are too large. The assembler does a fair job of allocating space to functions, -if- they are small. It is quite easy in HuC to create a function in C that generates more than 8K of machine code. Once that happens, the assembler will allocate a second 8K page for the rest of the code. Unfortunately, the rest of that page will be unused, leaving large chunks of unsused space.

I've actually never seen it do this... it bails if the function exceeds 8KB. I've had to split large functions into smaller functions manually because of it.

The assembler does a horrible job (or should I say "no job at all") at allocating space. It just sticks things in sequentially... and if the proc exceeds the free space of the current bank, it just goes on to the next one, creating plenty of potential waste. That's why I modified the assembler to spit out a list of how much each bank is using, along with the size of each proc, so functions in the C code could be reorganized to fit into RAM better.

[Hu-man]

If I'm breaking my functions into multiple smaller functions, do I need to worry about the number of calls that can be pushed onto the execution stack?

[Arkhan]

You won't really have to worry about that.  I doubt you will put enough things on the stack to wreck it.

And Rover, the bank wasting also happens if your function just barely extends the length of the page. 

Not necessarily because ONE function is >8K.

Functions larger than 8K are probably in need of a rewrite anyway.

[nodtveidt]

Ark, I already said that.

[Arkhan]

Ark, I already said that.

oh duhr,

I only read the top half of that.

Was on my Vita, lol