Include and call assembly within HuC

[megatron-uk]

Investigating a bit further now, does anyone have any examples of how to define/include assembly code within HuC and any calling conventions that are needed?

I see lots of demos/examples for pure C code for huc and the same for hu6280 assembly in pceas, but not much where the two are used together. Can someone point me in the direction of any code or demos that do this?

[OldRover]

Code Select Expand

#asm
;assembly code goes here
#endasmSimple as that.

[megatron-uk]

 

Doh. Simple as that eh?

Cheers!

[megatron-uk]

Ah, found the C/ASM integration comments in docs/huc/huc_doc.htm - I've been using http://www.archaicpixels.com/ for the HuC/pceas reference so didn't spot it straight away in my local docs.

[OldRover]

Archaic Pixels is a pretty good resource.

[TurboXray]

There's support in HuC for Pragma Fastcall, but no ever mentions or documents it. I've used it extensively. As you've probably already seen, the library is actually in all assembly. You can make your own assembly functions. Normally, when you make a C function in HuC, the compiler uses a software stack to pass arguments (and no, it doesn't modify the real stack - too small). Vars defined inside that function, also use a software stack (IIRC, it's been forever). You can get around it by using Global variables. But a much better method, once you get your code prototyped in C, is make an assembly version of it.

 Fastcall allows you to bypass the internal stack and use either A/X/Y and dedicated Zeropage bytes, for passing arguments (as if they're PROCs in magickit, but they actually don't use the proc directive). You can even do argument overloading with fastcall; one function - multiple number of arguments. You can also define the size of ~each~ argument (byte, word, 24bit, 32bit). And lastly, fastcall also allows direct code placement - sort of. You can define a fastcall function that has no code. I.e. instead of passing the arguments to Acc/X/Y or zeropage, it passed the arguments directly to a port. I did this for arcade card reg writes.

 You have to prototype your fastcall argument in C code, and then the actual code goes (usually) in the first library bank (because this bank is fixed, and is 'near' code). If you run out of room in the first Lib bank, remove some stuff, or put a 'far' code call in there (which is done for code in the second Lib bank).

 As Old Rov said, simply just placing #asm/#endasm directives anyway will give you quick access to assembly code. Not that global variables defined in HuC can be accessed with the same name, just add an under score in front of it. Accessing internal function defines vars with #ASM, is more complicated.

 Beware of pointer or array access in HuC. It's all treated as 'far' memory access, even static mapped ram, and code generated to access it is huge and slooow. Logic shifts are also pretty slow as well in HuC (go figure).

 Anyway, that's my 2 cents worth

[OldRover]

Aye... array performance is very bad. To get around it for code that would otherwise greatly benefit from it, I use single variables and end up duplicating a lot of code, or use "variable copy" methods. Code size suffers for it, but it's way faster than using straightforward code that utilizes arrays. Out of all the things that need to be addressed in HuC, array access is one of the most important.

[TurboXray]

How did you guys handle array/point access?

 I did two things. One, was just to write the array/pointer access with #asm/#endasm. The other was to create pragma fastcall functions that would return the byte or word in Acc or Acc:X.

 This:
var=array[index];

into:

var =get_array(array,index);

 etc. They were short/small functions that were fast. Since the top layer was Small C, you could easily do var=get_array(array,index++); or such. I wrote a bunch of little ones, depending on what I needed it to do. At some point, I was actually working on macro support - so the fastcall functions could be inlined. Though I think the inlined part, the way it was setup, had to be added to the source code of HuC. I added some support to HuC (the internal code itself, not the asm lib), but I never released it. You HuC guys seemed to not need it, and I didn't really need to use HuC for my own stuffs (though the idea of prototyping PCE code in C first, is appealing to me).

[Arkhan Asylum]

Insanity had a get/set that was just a c function that called inline assembly.

[TurboXray]

How do you guys handle that nowadays? Just lots of asm support?

[Arkhan Asylum]

How do you guys handle that nowadays? Just lots of asm support?

Same way basically.   It works and isn't that invasive.   I think OldMan has some other way to do it now.

[touko]

me apart , someone uses Huc with massive inline asm ???

[Arkhan Asylum]

me apart , someone uses Huc with massive inline asm ???

I put more and more inline assembly where it's needed.  Basically anywhere that does heavy array access is a good starting point for fixing.

It's still easier to write a complete game in C than it will ever be in assembly.   It always has been and always will be.

[touko]

I have started like that, but now is more easy and faster to write directly in ASM .
The code size is also lighter in ASM, more lighter ;-) ..

And like you said, huc is the only compiler where 9+1=12 lol ..

[OldRover]

I still don't get the 9+1=12 thing.

[TurboXray]

Maybe I should do a little game project with HuC. All these years of messing around with it and making libs, etc - and I've never actually sat down and made something with it.

[Arkhan Asylum]

I have started like that, but now is more easy and faster to write directly in ASM .

But then whatever you wrote isn't portable.  It's nice to be able to lift large chunks of the game code out to reuse in a new project, perhaps on a new platform.

That's part of why Insanity was so easy to port to the Xbox 360.  I copy pasted half the game.

[touko]

yes of course, i always forget that you develop on multiple platforms ..
But huc eats too many bytes/cycles for nothing .