The new fork of HuC

[elmer]

#define  IRQ_TIMER      0
#define  IRQ_VSYNC      1

These are duplicated in Squirrel. Deleting them causes a ton of errors.

Can't you just search-and-replace the ones in the Squirrel source file? Say to some like SQ_IRQ_TIMER?

[Bonknuts]

IRQ_TIMER and IRQ_VSYNC are used as bitmasks in HuC for enabling/disabling interrupts. Appending _MASK at the end would probably be a better name for them anyway.

[elmer]

IRQ_TIMER and IRQ_VSYNC are used as bitmasks in HuC for enabling/disabling interrupts. Appending _MASK at the end would probably be a better name for them anyway.

I wouldn't disagree ... but it might not be a easy change for DarkKobold to make (multiple files), and it might need the compiler to be rebuilt.

AFAIK Squirrel is a single (or maybe 2) files to change ... and anyway, library code like Squirrel shouldn't pollute the application programmer's global namespace, it's rude. 

[TheOldMan]

Squirrel is a single (or maybe 2) files to change

Funny thing is, I just did a find in all files (*.*) in the squirrel directory, and there were no hits.
I'm not saying it isn't there, just my editor didn't find it.

And yeah, DarkKobold, if you find it in the squirrel stuff, I'd change it to "PSG_ON_TIMER" and "PSG_ON_VSYNC". Should be more descriptive anyway. Afaik, they are only #defines for the parameter to one of the psg setup functions.

library code like Squirrel shouldn't pollute the application programmer's global namespace, it's rude.

If there were seperate namespaces, it wouldn't. However library code often has include files as part of the interface; using the #defines in them is recommended practice (just in case the values change)

System code and variables, however are supposed to use '__' or '_'  as a preface to indicate it's a system reserved value.

[TheOldMan]

[Don't know why, But I don't have an edit button, so....]

Okay, I finally found it. It's part of the defines for a test program. One of the squirrel examples. :/
To show people what values are useable, more than anything.

[cabbage]

Thanks to Bonknuts' generous help and source code, the entire HuC compiler and toolchain is now compiling cleanly on Windows with msys2.

Github has been updated with the latest changes, and a complete build of the latest version of HuC, with all the executables, include files, examples and source code can be found here ...

https://www.dropbox.com/s/kknwx1jqitizeap/huc-2016-11-03.zip?dl=0

If anyone downloads this and gives it a try, even perhaps, you know, like the folks involved in a certain high profile Kickstarter ... then I'd love to get some feedback on whether there are any problems (I hope not).  :-"

I downloaded this link and gave it a try on some code laying around, and I'm getting errors relating to farptr.

This first example is odd; the error seems sporadic and random even without changing the target code...
So, once it might show an error on one line number:

Code: [Select]

;error: player.c(167)
; load_vram(0x6400 ,hero_spr+0x3c0,0x40);
;                                      ^
;******  can't get farptr  ******Another time it might error on a different (but similar) line number:

Code: [Select]

;error: player.c(115)
; else if(i==8)load_vram(0x6400 ,hero_spr+0x80,0x40);
;                                                  ^
;******  can't get farptr  ******..And still other times it builds with no errors but the resulting binary doesn't work correctly. (everything is fine using the ancient build of HuC)

Another project always fails to build, and in the same way each time:

Code: [Select]

04:A267                  sta     <__fptr
Undefined symbol in operand field!
04:A27D                  sta     <__fptr+1
Undefined symbol in operand field!
04:A27F                  lda     [__fptr]
Undefined symbol in operand field!
Hope this helps~

[elmer]

I downloaded this link and gave it a try on some code laying around, and I'm getting errors relating to farptr.

Sorry to hear that!

There's a limited amount of debugging that I can do on the compiler, but let's try and get some of the obvious problems out of the way first.


It would be good to find out if I've broken something, either with my change to PCEAS, or with the mingw-w64 build itself.

Would you please try this version of HuC that I posted a few months ago?

It's built with cygwin using Artemio's source code without any changes ...

https://www.dropbox.com/s/4dy8tujysefqupd/huc-aurbina-2016-06-20.zip?dl=0


If that version still gives you problems, then what you're seeing is because of Uli's changes to the compiler.

If that version works, then we can continue to track down what's gone wrong with the new build.

Another project always fails to build, and in the same way each time:

Code: [Select]

04:A267                  sta     <__fptr
Undefined symbol in operand field!
04:A27D                  sta     <__fptr+1
Undefined symbol in operand field!
04:A27F                  lda     [__fptr]
Undefined symbol in operand field!

I'd focus on this project first! Debugging is so much easier with a reproducible problem.

Hope this helps~

Definitely, thanks!

I don't use HuC myself, and all that I've done is integrate Bonknuts's Windows-compatibility patch into the new compiler (with some of my own changes).

Since I don't use HuC, I'm going to have to rely on other people to come up with existing projects that the new compiler fails on.

[DarkKobold]

Squirrel is a single (or maybe 2) files to change

Funny thing is, I just did a find in all files (*.*) in the squirrel directory, and there were no hits.
I'm not saying it isn't there, just my editor didn't find it.

That is the crazy thing. I couldn't find where it was used either. I searched a ton, and as far as I can tell, its just in the "defs" .h file. That said, it wouldn't compile, and it looked to have something to do with the psg stuff, from squirrel. It may have actually been totally unrelated.

Maybe if someone pings Arkhan, we can figure this mess out.

[TheOldMan]

Maybe if someone pings Arkhan, we can figure this mess out.

<lol> He won't know. I have the original sources for the squirrel player, anyway.

I don't want to mess up my HuC installation (I need it for a game), so I'm working on
re-purposing another computer to install this new build. Once I get a generic "hello"
program compiling, I'll look into it a bit more. I do vaguely remember that there is an
attempt at doing the psg stuff in HuC, but it never got finished. That might be it.
Also note there appears to be a problem with far pointers; I've never used them, but
I'll be looking into that problem, too.

So if you are checking this out and have a problem, please post it here. We can't fix it if we
don't know what/how it broken.

[cabbage]

It would be good to find out if I've broken something, either with my change to PCEAS, or with the mingw-w64 build itself.

Would you please try this version of HuC that I posted a few months ago?

It's built with cygwin using Artemio's source code without any changes ...

https://www.dropbox.com/s/4dy8tujysefqupd/huc-aurbina-2016-06-20.zip?dl=0


If that version still gives you problems, then what you're seeing is because of Uli's changes to the compiler.

If that version works, then we can continue to track down what's gone wrong with the new build.

Another project always fails to build, and in the same way each time:

Code: [Select]

04:A267                  sta     <__fptr
Undefined symbol in operand field!
04:A27D                  sta     <__fptr+1
Undefined symbol in operand field!
04:A27F                  lda     [__fptr]
Undefined symbol in operand field!

I'd focus on this project first! Debugging is so much easier with a reproducible problem.

OK, I just tried with that 2015-10-14 build and got the same errors.

The code I have laying around is designed specifically with HuC in mind (ie, i would likely do things differently when using another compiler), so maybe it's just poor code whose support has been broken by uli's fixes? you're welcome to take a look at the example i used if you like.

[elmer]

OK. I got HuC compiled with the changes and removal of fmemopen. It compiles a simple source file, but pceas is complaining that it can find the x86 pseudo reg names (they now have an underscore). This looks to be a backend lib thing and not a executable issue (there were notes mentioning of moving and changing the asm lib stuffs).

EDIT: Nevermind about the x86 pseudo reg issue. Seems to be from add32() fastcall that's internal to HuC. No one bothered to change the names of the pseudo regs for the internal fastcalls to the match the changes to the backend lib. I'll update those now in HuC source code.. I'm not even sure why there are even internal fastcalls. Those should all be in the library..

Another project always fails to build, and in the same way each time:

Code: [Select]

04:A267                  sta     <__fptr
Undefined symbol in operand field!
04:A27D                  sta     <__fptr+1
Undefined symbol in operand field!
04:A27F                  lda     [__fptr]
Undefined symbol in operand field!

Hmmmm ... the problem that Bonknuts was seeing is the same type of error as the problem that cabbage has compiling his program.

Uli's new source files contain an inconsistent mix of "fptr" and "__fptr", just as though he was in the middle of changing things and then stopped part way through.

I've renamed all the instances back to their old HuC names "__fptr", and now cabbage's VWF test program compiles.

But it doesn't work properly, either with the old cygwin build, or with the new mingw build. 

...
<hours pass>
...

OK, cabbage's source code now builds and runs properly with the new compiler. 

The problem wasn't in his code, it was a change that Uli made in the new compiler.

Uli decided that "char" should be signed instead of unsigned, and that "#incbin" should define its label as a "signed char *".

This was breaking cabbage's program, and lots of other people's HuC programs probably, because that's different to how the old versions of HuC do things (and they were doing the sensible thing IMHO).

I've changed things so that #incbin always defines the label as an "unsigned char *", and I've changed the default char to be unsigned as well.

There are new compiler flags to change that default char setting "-fsigned-char" and "-funsigned-char".

With all of today's changes, cabbage's source code now compiles and runs properly with the latest version of the compiler.

The changes have been checked into github, and here is a new Windows 32-bit version of HuC ...

<EDIT - Removed obsolete build.>

Please let me know if folks still have problems with it.

[cabbage]

Great work, elmer! With this updated build, the other random error I spoke of is gone and the program compiles and runs just fine.

Since you asked, I found another issue. Here's an example program:

Code: [Select]

#include "huc.h"
char j;
#incpal(pal,"img.pcx");
#incchr(img,"img.pcx");
main(){
load_palette(0,pal,1);
for(j=0;j<64;j++){
load_vram(0x1000+0x10*j,img+j*0x10,0x10);
put_raw(0x100+j,j%32,j/32);
}
}And here's an img.pcx file to go with it.

HuC "Denki release" handles it just fine, but the new build gives an error:

Code: [Select]

HuC (v3.98-d31dfaa-dirty, 2016-11-05)
;error: test.c(8)
; load_vram(0x1000+0x10*j,img+j*0x10,0x10);
;                                        ^
;******  can't get farptr  ******It's due to the img+j*0x10 part -- by deleting +j*0x10, HuC stops complaining.

[Bonknuts]

It's not just +j*0x10 , but anything with j in the seconded argument. Even this causes a problems: load_vram(0x1000+0x10*j , j , 0x10). But somehow load_vram(0x1000+0x10*j , img , 0x10) compiles fine.

[elmer]

It's not just +j*0x10 , but anything with j in the seconded argument. Even this causes a problems: load_vram(0x1000+0x10*j , j , 0x10). But somehow load_vram(0x1000+0x10*j , img , 0x10) compiles fine.

The code to do the conversion from an arg_to_fptr() is in function.c

It's barely changed since the old HuC ... but looking at the information coming into it, I can't see how-on-earth it ever worked with complex values like "img+j*0x10".

It *seems* like the problem is in the code that checks to see if the argument is legal more than the actual code generation itself.

<EDIT>

I *suspect* that both the old & new code that checks the argument is basically wrong, and only worked before because the old code generator output the math in a very specific order, and wasn't very optimized.

Not sure how to fix this without opening up a can of worms.

[elmer]

I *suspect* that both the old & new code that checks the argument is basically wrong, and only worked before because the old code generator output the math in a very specific order, and wasn't very optimized.

Not sure how to fix this without opening up a can of worms.

I've rewritten the arg_to_fpt() function to deal with the optimizations that Uli made in the expression parsing.

HuC should now get passed all the variations of input code that cabbage was throwing at it.

It can still get confused, and will give errors on some legal-but-unusual ANSI  C code, but it should work for all common usage, and it is no worse (IMHO) than the code that was previously in there.

The changes are checked into github, and there's a new build here ...

<Removed link to obsolete version>