|
Post by dshadoff on Dec 7, 2021 15:25:33 GMT
pseudo-ops, back on all the assemblers I used in the 80's, resembled opcodes from a source point of view. As did the invocation (but not necessarily the definition) of macros. But I guess you're calling out the inconsistency here, where some are prefixed and others are not...
|
|
|
Post by elmer on Dec 7, 2021 16:05:42 GMT
But I guess you're calling out the inconsistency here, where some are prefixed and others are not... Yes, but you can just ignore me! I'm feeling grumpy because I couldn't add "set", and so have made the pseudo-ops inconsistent ... and now I'm battling with github, which is never pleasant.
|
|
|
Post by elmer on Dec 7, 2021 20:06:22 GMT
For folks that remember the example of HuC output from earlier in this thread, corresponding to the C code animtimer[pc]--; Here is what KickC does with a similar piece of test code. C version ... #pragma target(pce)
#pragma data_seg(Data) __export unsigned long myval [2] = { 0x12345678, 0x87654321 }; char message[] = kickasm {{ incbin "NOTICE.txt" }};
#pragma data_seg(Bss) char animtimer[4]; char pc;
// This decrements ... void decrement (void) { animtimer[pc]--; }
/* ** This calls "decrement" ... */ void main() { pc = 0x81 + (32 * 2); decrement(); pc = message[0]; decrement(); }
ASM output, which now assembles correctly with the latest changes to PCEAS ... #[1] test.asm 3 .kickc 4 5 6000 .segment Code 6 /* 7 ** This calls "decrement" ... 8 */ 9 main: { 10 // decrement() 11 02:6000 A2 C1 ldx #$81+$20*2 12 02:6002 20 0C 60 jsr decrement 13 // pc = message[0] 14 02:6005 AE 08 40 ldx message 15 // decrement() 16 02:6008 20 0C 60 jsr decrement 17 // } 18 02:600B 60 rts 19 } 20 // This decrements ... 21 decrement: { 22 // animtimer[pc]--; 23 02:600C DE D2 22 dec animtimer,x 24 // } 25 02:600F 60 rts 26 } 27 4000 .segment Data 28 06:4000 78 56 34 12 myval: .dword $12345678, $87654321 06:4004 21 43 65 87 29 06:4008 message: 30 06:4008 incbin "NOTICE.txt" 31 22D2 .segment Bss 32 --:22D2 animtimer: .fill 4, 0
|
|
|
Post by turboxray on Dec 8, 2021 17:25:07 GMT
Since you have {}, does that mean you can use sizeof() on it??? Or better yet, also have the assembler auto generate a name._sizeof var with the size (the dream!)
|
|
|
Post by elmer on Dec 8, 2021 18:01:37 GMT
You can't currently use sizeof(), but that's an easy thing to add, and an obviously-useful bit of functionality. Great thinking! I'm a little less clear on why you want that label? Is it for use inside KickC code (which doesn't currently have a "sizeof" operator available)? IIRC, HuC already supports PCEAS's sizeof() operator, so I don't think that you want it for that. Along a line of similar thinking, I was already contemplating adding in an auto-generated label name for when PCEAS creates a code-trampoline for a procedure, so that you could write code to call it directly if you wanted. But I think that it's probably just better to make a JSR always call the code-trampoline if you're in .kickc mode ... well, actually it should *always* do that anyway if we're going to use the shorter 10-byte code-trampoline.
|
|
|
Post by turboxray on Dec 8, 2021 23:58:31 GMT
You can't currently use sizeof(), but that's an easy thing to add, and an obviously-useful bit of functionality. Great thinking! I'm a little less clear on why you want that label? Is it for use inside KickC code (which doesn't currently have a "sizeof" operator available)? IIRC, HuC already supports PCEAS's sizeof() operator, so I don't think that you want it for that.Along a line of similar thinking, I was already contemplating adding in an auto-generated label name for when PCEAS creates a code-trampoline for a procedure, so that you could write code to call it directly if you wanted. But I think that it's probably just better to make a JSR always call the code-trampoline if you're in .kickc mode ... well, actually it should *always* do that anyway if we're going to use the shorter 10-byte code-trampoline. I want it for PCEAS. I already have macros have do this (and for some things I manually do this).. so I can pass the primary name/label to a macro that assumes it's like an object; it has a .sizeof value to the name/label. I tend to write my macros that take a name like it would be an object and expect sub labels via the "." in the name. It's just super convenient. Like for my game: I have a data structure with a top level name called "Spider_001". And that data structure has something like .celldata, .celldata.size, .cramdata, .cramdata.size, etc. I only have to pass the top level name to whatever macro and it appends the needed sublabels it expects to be there (a macro to copy to vram, a macro to copy cram data to vce.. all with one just the primary label). I could leverage myData { .db 1,2,3,4,5,6 }, and if I pass around the primary label "myData" to a macro, it could do \1.sizeof inside that macro. I mean it's not a huge deal but it would be convenient if it autogenerated it and it's expected to be there.
|
|
|
Post by dshadoff on Dec 9, 2021 0:23:40 GMT
For this purpose, I agree that sizeof would be useful… In the past, I have put a label before the include and a label after the include, and then did a “.dw label2-label1”
|
|
|
Post by elmer on Dec 9, 2021 3:22:40 GMT
In the past, I have put a label before the include and a label after the include, and then did a “.dw label2-label1” Did you know that PCEAS already includes a SIZEOF(), although what it actually does is pretty hard to define from the documentation ... Predefined functions --------------------
...
SIZEOF() - Returns the size of a data element.
In the case of an ".incbin" or something like a ".incspr", PCEAS actually stores the number of bytes loaded as an attribute of the last label, and then you can read that attribute with the SIZEOF() function. There are a bunch of other data definitions that set a symbol's "data_size" attribute too ... it's a magical rabbit-hole to dive down!
|
|
|
Post by elmer on Dec 9, 2021 15:25:11 GMT
I want it for PCEAS. I already have macros have do this (and for some things I manually do this).. so I can pass the primary name/label to a macro that assumes it's like an object; it has a .sizeof value to the name/label. I tend to write my macros that take a name like it would be an object and expect sub labels via the "." in the name. It's just super convenient. Wow, you're writing some pretty amazing stuff, and pushing the boundaries of the assembler! Yep, I'll absolutely add the "_sizeof" label to the scope when it is closed. BTW, that does bring up an issue ... if you're going to make heavy use of "label scope" for cool PCEAS code, then can we please come up with a PCEAS-specific set of names to invoke it, say ".scope/.ends", or maybe ".struct/.ends"? I say this becuase I put in the KickAssembler's "{}" specifically for KickC code, because it uses that syntax for C functions. While those just currently act as normal code, I need to reserve the ability to change things in the future and say that "{}" also implies ".proc/.endp", so that the C functions can be relocatable, just like HuC functions are.
|
|
|
Post by elmer on Dec 11, 2021 15:05:51 GMT
BTW, that does bring up an issue ... if you're going to make heavy use of "label scope" for cool PCEAS code, then can we please come up with a PCEAS-specific set of names to invoke it, say ".scope/.ends", or maybe ".struct/.ends"? If nobody chimes in on this, I'm just going to use ".struct/.ends" (and "struct/ends") for the PCEAS version of this, and then "{}" will only be usable while in ".kickc" mode. FWIW, the "_sizeof" label has been added, and you can also use the SIZEOF() function on the structure's opening label to get its size. On top of that, another change is that all address/location labels now store the final bank number of the label in bits 23-31 of the label value. This allows you to get the bank number with a simple "mybank = (mydata >> 23)" instead of using the BANK() function. <EDIT> Or maybe ".class/.endc" or ".obj/.endo" I don't know ... but ".struct" seems weird when the example used has code inside it!
|
|
|
Post by turboxray on Dec 11, 2021 15:59:11 GMT
The struct/ends works.
|
|
|
Post by elmer on Dec 12, 2021 1:29:40 GMT
Implemented, and checked-in to github.
|
|
|
Post by DarkKobold on Dec 13, 2021 0:57:55 GMT
For folks that remember the example of HuC output from earlier in this thread, corresponding to the C code animtimer[pc]--; Here is what KickC does with a similar piece of test code. C version ... #pragma target(pce)
#pragma data_seg(Data) __export unsigned long myval [2] = { 0x12345678, 0x87654321 }; char message[] = kickasm {{ incbin "NOTICE.txt" }};
#pragma data_seg(Bss) char animtimer[4]; char pc;
// This decrements ... void decrement (void) { animtimer[pc]--; }
/* ** This calls "decrement" ... */ void main() { pc = 0x81 + (32 * 2); decrement(); pc = message[0]; decrement(); }
ASM output, which now assembles correctly with the latest changes to PCEAS ... #[1] test.asm 3 .kickc 4 5 6000 .segment Code 6 /* 7 ** This calls "decrement" ... 8 */ 9 main: { 10 // decrement() 11 02:6000 A2 C1 ldx #$81+$20*2 12 02:6002 20 0C 60 jsr decrement 13 // pc = message[0] 14 02:6005 AE 08 40 ldx message 15 // decrement() 16 02:6008 20 0C 60 jsr decrement 17 // } 18 02:600B 60 rts 19 } 20 // This decrements ... 21 decrement: { 22 // animtimer[pc]--; 23 02:600C DE D2 22 dec animtimer,x 24 // } 25 02:600F 60 rts 26 } 27 4000 .segment Data 28 06:4000 78 56 34 12 myval: .dword $12345678, $87654321 06:4004 21 43 65 87 29 06:4008 message: 30 06:4008 incbin "NOTICE.txt" 31 22D2 .segment Bss 32 --:22D2 animtimer: .fill 4, 0
I'm confused here. It seems like this could potentially reduce code size massively, as well as increase performance. How do KickC, HuC, and PCEAS work together? Being able to save huge ROM space would help massively.
|
|
|
Post by elmer on Dec 13, 2021 3:44:52 GMT
I'm confused here. It seems like this could potentially reduce code size massively, as well as increase performance. How do KickC, HuC, and PCEAS work together? Being able to save huge ROM space would help massively. At this point ... they don't. It is still early-days, and what you're watching is an investigation to see *IF* KickC *MIGHT* be useful on the PC Engine in the future. Its code-generation is leaps-and-bounds over HuC, which is nice to see ... but it is not now, and never will be, 100% compatible with HuC. At best it would be a whole new way of developing for the PCE, and it would require learning a bunch of new techniques (and limitations). But "yes", its appeal is in the possibility of getting faster code and huge savings in ROM space ... maybe ... hopefully.
|
|
|
Post by DarkKobold on Dec 13, 2021 19:17:10 GMT
I'm confused here. It seems like this could potentially reduce code size massively, as well as increase performance. How do KickC, HuC, and PCEAS work together? Being able to save huge ROM space would help massively. At this point ... they don't. It is still early-days, and what you're watching is an investigation to see *IF* KickC *MIGHT* be useful on the PC Engine in the future. Its code-generation is leaps-and-bounds over HuC, which is nice to see ... but it is not now, and never will be, 100% compatible with HuC. At best it would be a whole new way of developing for the PCE, and it would require learning a bunch of new techniques (and limitations). But "yes", its appeal is in the possibility of getting faster code and huge savings in ROM space ... maybe ... hopefully.
I mean, 100% compatibility with legacy HuC shouldn't even be a requirement. Most developers shouldn't expect that.
I'm used to porting my code to completely different platforms at this point, GBDK, SGDK, monogame, etc. I think staying in the same platform would be monumentally easier, even if there's some basic library changes.
|
|