I didn't look over load_vram's second argument. Is it expecting a far_ptr as the argument type? Is it just a matter of the expression inside of the second argument not returning a far_ptr type?
Yes, it was all a problem with converting the second argument into a far_ptr type.
HuC needs to figure out which bank contains the address that you're trying to use for that 2nd parameter.
The code that it uses to figure that out is in arg_to_fptr().
Unfortunately, that code doesn't have full access to the all the syntactic information that it needs, and has to guess at which symbol the programmer wants to use as the base address just from looking at the I-CODE stream (the intermediate code representation).
The old HuC code that was in there couldn't handle the changes that Uli made in the expression parsing to produce a more-optimized I-CODE sequence.
I had to experiment to see what kinds of I-CODE sequences are now produced for the common types of C-usage that are going to be written by HuC programmers.
Then I had to figure out how to determine where the base address is, but still reject the common illegal-parameter errors that programmers often make.
The end-result is very similar to the original HuC code, but it's a bit more flexible in its ability to handle the different I-CODE streams that Uli's changes produce.
************
Even though there are still niggles like these to fix, I'm really impressed with all the work that Uli put into improving the HuC compiler.
It's pretty amazing that it's gone from using 54 different I-CODE functions in the old HuC to 94 now.
That's a
lot of new codes to allow him to optimize the output that HuC generates!
