The new fork of HuC

[Bonknuts]

https://github.com/uli/huc

 So is anyone interested in using this?

On a side note:
 I downloaded the source and tried to compile it under gcc using code:blocks, but it errors out on fmemopen() reference. I looked it up, and according to gnu it's part of stdio.h (http://www.gnu.org/software/libc/manual/html_node/String-Streams.html). But when I look at stdio.h from mingw include folder, fmemopen (as well as open_memstream) is not declared in the file. Why would mingw exclude this in stdio?

Update:
Commenting the fmemopen reference...

Code: [Select]

/*if (!data)
data = fmemopen(data_buf, DATABUFSIZE, "w");
if (!rodata)
rodata = fmemopen(rodata_buf, DATABUFSIZE, "w");
    */
And it compiles without problems. Just need to figure out how to re-implement fmemopen in mingw.

[elmer]

But when I look at stdio.h from mingw include folder, fmemopen (as well as open_memstream) is not declared in the file. Why would mingw exclude this in stdio?

Presumably because it's of limited practical-use, and can be replaced reasonably-easily where it has been used ... which it obviously isn't in the hundreds of packages that mingw-w64 does support.

It was a bit lazy of Uli to use it, but he did, and now it's up to someone else to fix it if they don't want to compile under cygwin on Windows.

It's just being used to buffer and rearrange different sections in the HuC output. That's something that Uli added, and it wouldn't be too tough to implement the same functionality in a different way that didn't need fmemopen().

BTW ... I'd recommend using Artemio's fork-of-Uil's-fork rather than Uli's version. Artemio fixed a few things after Uli stopped working on it.

You may have missed my cygwin build of it here ...

HuC - Newbie questions?
http://www.pcenginefx.com/forums/index.php?topic=21136.msg461615#msg461615

It's definitely a little better than the old HuC ... but not leaps-and-bounds.

To be blunt ... no matter how much lipstick you put on the pig, it's still a pig.

HuC was wonderful for its time ... but it's architecturally hamstrung because of its Small C origins.

Eric Petrich (the SDCC developer that I've been working with) recently "went public" and created a new SDCC branch in the main SDCC codebase on SourceForge for the new 6502 compiler port.

Since he's actually one of the main SDCC developers ... that means that it's all going to eventually get rolled into the main SDCC codebase when it's finished.

But, to be honest, I've haven't been as active as I should be in helping him get the SDCC port done.

It's my current task to add 6502 support to the ucsim simulator that's going to be used for automated-testing of the 6502 port, but I've been too busy with the Xanadus, and PC-FX GCC, and now in preparing to disappear into the desert for a week.

IMHO ... if you want to take the time to try to improve C on the PCE, then may I suggest that you consider helping out the SDCC port rather than applying yet-another layer of small fixes to HuC?

[Bonknuts]

To be blunt ... no matter how much lipstick you put on the pig, it's still a pig.

 Well, I was thinking of a new different shade of lipstick; Objective Small C. Ok, maybe not as advance as the original pre-processor of Objective C, but something along the lines of it. Something to toy with for a future class project.

[Sunray]

I've used it for about a year now. I use Cygwin for compiling and you can use the compiled exe without Cygwin later, just need to have a cygwin dll copied alongside the exe files.

I would not have started doing PCE homebrew without this fork.

[DarkKobold]

So, I'm using "vanilla" HuC. The thought of having to install Cygwin to compile a new version of HuC sounds less fun that punching myself in the nuts. What benefits are there to switching to a new version of HuC? (EDIT: Saw elmer provided a download. Will try it. Still curious what the benefits are.)

Additionally, HuC might be a lipstick wearing pig, but she's gettin' the job done to build a homebrew, that would have never existed had it need to be written in ASM. I can't think of anything less fun than writing 6802-style ASM. Maybe compiling a compiler.

[touko]

I can't think of anything less fun than writing 6502-style ASM

Hu6280's asm is fun, really 

Huc is really fun to start with PCE coding, but it shows it's limits quickly .

[elmer]

Well, I was thinking of a new different shade of lipstick; Objective Small C. Ok, maybe not as advance as the original pre-processor of Objective C, but something along the lines of it. Something to toy with for a future class project.

One of the best aspects of HuC is that it's a simple-enough compiler to "play" with.

You might also consider modifying LCC, if you want a well-documented (there's a book) C compiler to play with.

I've got to say that I found the SDCC code to be incomprehensible to me.  :oops:

What benefits are there to switching to a new version of HuC? (EDIT: Saw elmer provided a download. Will try it. Still curious what the benefits are.)

A whole bunch! 

ANSI C syntax instead of the horrible old K&R syntax is the most immediately-obvious.

Just look at the README in the link that Bonknuts put in the 1st post in this thread.

I would not have started doing PCE homebrew without this fork.

Additionally, HuC might be a lipstick wearing pig, but she's gettin' the job done to build a homebrew, that would have never existed had it need to be written in ASM.

Comments like these show that there's a desire for a C compiler for PCE development, and HuC has been wonderful for that.

It's just that there are much better open-source compiler front-ends available these days than Ron Cain's Small C, and it should be possible to generate much better 6280 code than HuC can ever be "fixed" to generate.

Until that happens, HuC (or Uli-fork-with-Artemio's-improvements) is the best option for folks.

[Sunray]

Clang + LLVM backend for Hu6280 would be optimal. HuC works fine for me but a better compiler would mean more advanced homebrew.

In my homebrew game the game code is cross platform and the PCE backend is a mix of HuC + asm. I plan to port it to Amiga and SNES in the future (if I ever finish it). Without C this would not be possible.

[Bonknuts]

Been trying to make sense of fmemopen and how it's used. I think I got this figured out. It'll be kind of a hack, because how he reused functions pointing to file streams instead of buffers, but I could change data and rodata to actual fopen(). There's a point where data and rodata get fclose() and just the data from the buffer is transferred to the main output stream (output) - this is in dumpfinal(). This could be changed to a simple read the file contents back into the buffers, then pass those buffers along.

 No where else is fmemopen() used except in main.c and in the global definition section dumpglbs().

 That, or where everything eventually gets routed to a single fputc() output, a little bit of conditional code to handle writing directly to the data/rodata buffers upon detection. Either should work and remove the cygwin dependency.


 Note: Not that I write the most beautiful code, but goto and continue usage seems.. I dunno, out of place. Feels hack-y/rushed in code design instead of thought out. I shouldn't criticize, really. But it is strange to see it there.

 Edit: Meh.. I'm just gonna rewrite *buffer version of all the fstream functions. There's not that many. It'll be more readable.

[Bonknuts]

More Posix specific stuff that's not in mingw (lock and unlock stuffs for File streams), but this time in pceas.

[Bonknuts]

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

 Elmer, is that link from your drop box Artemio's fork?

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

 Here's the modified main.c for mingw
(edit: I'll upload it as complete source package and binary snapshot once I get enough testing done. So far, so good.)

[elmer]

OK. I got HuC compiled with the changes and removal of fmemopen.

Excellent! Congratulations! 

Elmer, is that link from your drop box Artemio's fork?

Yes,  the build that I made was from Artemio's github fork.

Good luck! 

[Bonknuts]

Ok. Do you know what the differences are? I looked at the git that I posted at the top of this thread, and saw the pull requests from Artemio and trap (and someone else). They even submitted the changed files (trap did switch case extension to 256 levels, and re-wrote code for pcxtool - needed for dealing with photoshop's PCX format). Artemio's pull request was just for PCEAS and better bank sorting. Did he touch HuC at all? Did he have a git page?

[Bonknuts]

Update: Just testing out some features of the 3.98 HuC build. Seems const arrays can be populated during compile time, but variable arrays can not be populated during runtime. But that's not the issue per se; it's how HuC is handling the error messages. It's hard locking the program.

 I'm gonna run the compiler through the gnu debugger with PCE C source files known to cause HuC errors, to see what's happening.

 Update2: Wow! Looking at variable array direct access and it's fast. Very nice. Pointer into array isn't that bad either (IIRC it was treated as far access in HuC 3.21, not so in this release).

 Update3: I'm looking at the code generation for pointers and arrays, and I'm pretty happy with the improvement. Though there's one thing that could be improved further; if the index into an array pointer (if char *x, then x=array, x[i ] =0) is smaller than 256, it should be indexed by Y instead of added to the pointer manually (it's a 16bit add regardless of the value for the code generation).

[elmer]

Ok. Do you know what the differences are? I looked at the git that I posted at the top of this thread, and saw the pull requests from Artemio and trap (and someone else).

When you're on Uli's github web page, just click on the number to the right of "Fork" near the top of the screen.

That'll take you to the revision graph. You can click on any of the different fork's revisions on that graph and it will take you directly to the github page for that fork/revision.

That's the easiest way (that I know of) to get to Artemio's page from Uli's page.