The new fork of HuC

[elmer]

Said folks will give this all a spin soon enough.

Excellent! 

I should have the current bug fixed soon ... I think that the quick-and-dirty fix is safer at this point than changing the macros to allow for an offset parameter. The behavior of those macros is relied upon in too much of the optimizer code.

The next question is ... are you open to a change in the HuC register usage? 

HuC currently uses A:X for the 16-bit accumulator, and Y is used mostly for slow stack accesses (being set to the value 1).

Changing that to have the 16-bit accumulator in Y:A, and using X to be the data-stack-pointer offers a considerable performance and size benefit when matched with a zero-page stack.

That stack can be tiny (probably 8-bytes or less) if you're using all of the current HuC tricks to have global variables and avoid the stack ... but if you give it a 32-byte or 64-byte stack, then you can probably avoid needing to use most of those tricks and just rely upon the compiler to auto-magically use the stack for local variables, and have it run as fast as putting everything into zero-page.

Remember that on the PCE, the "zero-page,x" addressing mode is just as fast as the basic "zero-page" addressing mode.

It'll need some improvement to the HuC optimizer to take full advantage of the capability ... but the main assembly-language code generation and libraries are looking good so far.

[elmer]

Next question ... does anyone have a HuC project that they would be willing to share with me for testing?

I really need to see a reasonable-sized project in order to test the changes to HuC.

Uli's new testsuite is great ... but it has obviously missed a few problems with the new compiler that I've been having to fix.

If I make more-radical changes, then I'll need a better test.

[DarkKobold]

Next question ... does anyone have a HuC project that they would be willing to share with me for testing?

I really need to see a reasonable-sized project in order to test the changes to HuC.

Uli's new testsuite is great ... but it has obviously missed a few problems with the new compiler that I've been having to fix.

If I make more-radical changes, then I'll need a better test.

Elmer, greds and I chatted about it. We wouldn't mind sharing catastrophy, in its current state. That said, there are a few obvious and not so obvious caveats before we just dump our code and such to you.

Lets chat via PM?

[Gredler]

Elmer, greds and I chatted about it

"grovy"

[elmer]

Elmer, greds and I chatted about it. We wouldn't mind sharing catastrophy, in its current state. That said, there are a few obvious and not so obvious caveats before we just dump our code and such to you.

Lets chat via PM?

That would be absolutely perfect ... I hoped that you'd volunteer. 

I'll send you a PM.

[Arkhan]

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.

errr.

Those defines can be omitted, or renamed.   They're just convenience defines for calling psgOn in your code for readability from what I remember.

I am pretty sure Atlantean just does psgOn(1) and doesn't even use the define.

what *other* explosions happen?  Rename those defs to anything you want, or omit them.

I don't have the new fork of HuC, so I can't really comment on it.  I'm also balls deep in MSX stuff so I am not really itching to grab it and start swinging at it...

but if you copy paste errors, I can try to help. 

[Arkhan]

But someone should have re-written that crazy ___case function *years* ago!!! 

It's coming right after that MOD player comes out next week in 2007 or 8. 

[nodtveidt]

Stoned af.

[elmer]

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

I agree ... at least within some reasonable limits. 

Uli deciding to change the old System Card parameter names from "_al", "_bx", etc so that you could use variable names "al", "bx" etc in your HuC code, was the correct (IMHO) idea, but he went in the wrong direction (also IMHO).

He changed them to "al", "bx", etc in assembly language ... which just means that they conflict with a programmer's own usage of simple names for their own variables.

So I've changed them in the opposite direction ... the System variables are now "__al", "__bx", etc in assembly code, and can be referred to directly in HuC as "_al", "_bx", etc (since C prefixes an '_' onto all variables.

This makes it easier to differentiate System and HuC internal variables from C variables, from assembly-language variables.

[elmer]

Well, Catastrophy has shown that there's something going wrong somewhere in Uli's new optimizations in HuC. 

This C code fails ...

  const char a[6] = {60, 61, 62, 63, 64, 65, 66};

  main()
  {
    char x,y,z;
    x = 2;
    y = 3;
    z = a[x+y];
    if (z != 65)
      exit(1);
    return 0;
  }

This will take some serious debugging to find out what's going wrong! 


*************************************

While I'm at it, it gives me an excuse to talk about *why* rearranging the register usage would be an improvement.

The example above generates assembly language code that uses the "__stbps" macro.

That macro stores a byte at the location whose address is on the top of the stack.

That's not uncommon when doing any array indexing or storage through pointers.

Here's what that macro does in Uli's HuC now ...

====================

 pha
 phx
 lda   [__stack]
 tax
 ldy   #1
 lda   [__stack],Y
 stx   <__ptr
 sta   <__ptr+1
 pla
 plx
 sta   [__ptr]
 sax
 inc   <__stack
 inc   <__stack

22 bytes, 62 cycles

====================

And it's even bigger and slower in the old HuC that doesn't have the "-msmall" small stack option! 


Here's the same thing with the rearranged registers and the zero-page stack that I'd like HuC to use ...

====================

 sta [__stack,x]
 inx
 inx

 4 bytes, 11 cycles

====================

[TheOldMan]

  const char a[6] = {60, 61, 62, 63, 64, 65, 66};

That should be a[7]. There are 7 values.

    if (z != 65)

This may be your problem. The original HuC would see the 65 as an int, and then screw up the compare. IIRC, it would compare two bytes, using the byte after z as the high byte for the compare.

Not sure thats the problem, but you might want to check it. HuC really doesn't llike it when you mix types.

[elmer]

That should be a[7]. There are 7 values.

Whoops ... that's just a typo in my post.  :oops:

The test array actually has 10 bytes, but I hand-edited it to make it smaller in the post.

This may be your problem. The original HuC would see the 65 as an int, and then screw up the compare. IIRC, it would compare two bytes, using the byte after z as the high byte for the compare.

Good point, but AFAIK, it's a bit better about those comparisons now.

The actual problem is that the optimizer turns

z = a[x+y]    into    a[0] = z[x+y]

That's a big screwup!

<EDIT>

It's actually probably just a 1 line typo somewhere that causes the error to propagate into that terrible result.

[TheOldMan]

z = a[x+y]    into    a[0] = z[x+y]

Looks like somebody got the macro parameters backwards...

[Gredler]

just a 1 line typo somewhere that causes the error to propagate into that terrible result.

This is what gets me about programming, the room for error for an error prone person makes a difficult learning curve!

The above convo sounds awesome though, seems like progress is progressing!

Stoned alf.

That's not supposed to be alf, it's supposed to be a cat, my drawing skills need to improve like HuC is!

[elmer]

Looks like somebody got the macro parameters backwards...

Hahaha, yes, that's exactly what it looks like, doesn't it! 

Actually, I've already found *where* the problem is ... but now I've got to find out *why* it's going wrong.

It's in an incredibly excellent new optimization that Uli added that will be critical (in the future) to getting good performance out of the zero-page stack.

It's moving the wrong address from the stack to the end of an assignment ... it's grabbing the address from one I-CODE too soon.

Now ... *why* 

This is what gets me about programming, the room for error for an error prone person makes a difficult learning curve!

IMHO, access to a good source-level debugger is crucial to learning as a beginner.

Unfortunately, there's very little that we can do about that on the PCE.