|
Post by DarkKobold on Nov 17, 2021 0:12:23 GMT
So is this "memory management" advantage something that will allow devs to more easily optimize their data and code against usable space? Is that what I should be taking away from this?
Default PCEAS/HuC wastes a lot of space - some of it on library functions that never get used, some of it on the final bank (trampoline bank?) which tells the processor where functions are. The end users of HuC don't really get a lot of control over this waste - for Jessie CD to work, I had to manually cull stuff from HuC, and shove graphics into the library banks manually. Strangely, despite the CD being "a ton more space" it actually gives the programmer less to work with (256kB instead of 1024kB) because you don't want to stop the music to load data mid-level. Elmer also gave an example of why HuC is incredibly wasteful when doing array access. Catastrophy is around 50% code, whereas ASM written games back in the day were only around 10% code. So, every byte counts when making a game.
It sounds like elmer's improvements manage some of this waste without user intervention. Hopefully turboxray will be able to incorporate it into his version with the sound engine.
<script src="moz-extension://45e2808e-8f70-4511-8bd5-7ce38a0f464b/js/app.js" type="text/javascript"></script>
|
|
|
Post by elmer on Nov 17, 2021 1:44:51 GMT
So is this "memory management" advantage something that will allow devs to more easily optimize their data and code against usable space? Is that what I should be taking away from this? Default PCEAS/HuC wastes a lot of space - some of it on library functions that never get used, some of it on the final bank (trampoline bank?) which tells the processor where functions are. The end users of HuC don't really get a lot of control over this waste - for Jessie CD to work, I had to manually cull stuff from HuC, and shove graphics into the library banks manually. Strangely, despite the CD being "a ton more space" it actually gives the programmer less to work with (256kB instead of 1024kB) because you don't want to stop the music to load data mid-level. After having been through the process of trying to optimize a HuC project for release, DK understands what the problem is, and what this change in PCEAS is trying to improve. HuC, because of the way that it is constructed, creates a few partially-filled banks of code & data that contain unused memory areas that it isn't possible for a HuC developer to easily use ... the developer just has no way to predict where the space is, nor does HuC provide any reasonable means for using that space. Specifically, that applies to the CONST bank, the "User Program" bank, the end of the "DATA" area, and the end of the HuC procedures that it generates from the developer's "C" code. In addition, as he says, there is also a chunk of library code that is included by default, even if the game doesn't use it, and that code is another thing that does not use all of the space within the banks that it allocates for itself. While it is certainly possible to use all of the tricks that he employed to make good use of that otherwise-wasted space, and to analyze the HuC libraries and manually chop out the stuff that you don't need, the whole process takes a lot of time and mental energy, and it causes a lot of frustration for the developer(s). The work that I have been doing to PCEAS recently is aimed at automating a lot of that process, so that the developer has to do very little manually. Now that work is primarily aimed at my own needs for assembly-language development, but some of it applies to current HuC users, and some of it could also apply to HuC users in the future, if the existing MagicKit libraries that HuC uses were made more modular. It sounds like elmer's improvements manage some of this waste without user intervention. In the specific case of yesterday's change, DK is correct, and the improvement is entirely automatic ... he, and any other HuC users that want it, just need to build and use the version of PCEAS that is in my HuC repository on github. Elmer also gave an example of why HuC is incredibly wasteful when doing array access. Catastrophy is around 50% code, whereas ASM written games back in the day were only around 10% code. So, every byte counts when making a game. Yep, as an assembly-language programmer, I nearly had a heart-attack when I saw that Catastrophy was using 293KB of HuC-generated program code! There really isn't much that either turboxray or myself can do to help with that. IMHO, it would take an absolutely Herculean effort to improve HuC's peephole-optimizer to where that was 40% instead of 50%!
|
|
pokun
Gun-headed
Posts: 85
Homebrew skills: HuC6280 assembly
|
Post by pokun on Nov 23, 2021 21:46:37 GMT
Many nice updates indeed. I'm not sure about the include guard thing though. Normally I would expect it to include two copies of the same file twice if I told it to, though I'll admit I've never really done that. I guess you could always add an option or directive that changes the behavior.
One question: do these changes apply to Nesasm as well? If you change the filename of pceas to "nesasm.exe" it should work as the Famicom/Nes assembler Nesasm. Nesasm could really use these changes.
|
|
|
Post by elmer on Nov 24, 2021 0:48:51 GMT
I'm not sure about the include guard thing though. Normally I would expect it to include two copies of the same file twice if I told it to, though I'll admit I've never really done that. I guess you could always add an option or directive that changes the behavior. Making the behavior optional is certainly possible ... but I'd prefer not to implement that until someone comes up with a realistic example of why you'd want to include two copies of the same code, that couldn't be achieved (possibly easier) with some other method. One question: do these changes apply to Nesasm as well? If you change the filename of pceas to "nesasm.exe" it should work as the Famicom/Nes assembler Nesasm. Nesasm could really use these changes. I have not specifically tried to limit anything to PCEAS, and to exclude NESASM (or FUJIASM), but honestly, I've not actually tested NESASM because I don't use it. If you find that something that you'd like to use doesn't work, then just let me know and I'll try to fix it. BTW ... I didn't know that anyone was actually using NESASM these days, may I ask you what advantages you find in using it over the (many) other NES development tools?
|
|
pokun
Gun-headed
Posts: 85
Homebrew skills: HuC6280 assembly
|
Post by pokun on Nov 24, 2021 23:30:14 GMT
Actually I don't use Nesasm either and haven't for ages (I use either Asm6 or 64tass for 6502 and 65816), I was mostly curious. There are uses of Nesasm though, it's a simple assembler like Asm6 and yet more powerful so I can see why some people still prefer it. And then there is the PpMCK sound library which is written for Nesasm. It's useful for making NSFs.
I might give Nesasm a try someday again to see if the improvements work.
|
|
|
Post by elmer on Nov 29, 2021 15:52:39 GMT
turboxray mooz : In PCEAS 3.22, way back in 2012, you added this ... Local labels how have -/+ support… sort of. You still need the ‘.’ character to signify/define a local label name, but now you can use .- or .– and .+ and .++ etc. You can use them in higher level math/logic operations too and inside EQUATE defines. You just need whitespace between the end of the name and the – or + operator, *IF* your label ends with a – or +. So test = .+++ + $10 works fine, but so does test1 = .skip+$10. The new labels for local doesn’t not break backwards compatibility with otherwise normal label names. I’m not a big fan of the -/+ usage as it can messy looking real quick in my opinion. But couple of people had requested it. Plus, it would make converting some c64 or such code a little easier (I mean, for when you’re lazy).
I'm confused by this syntax, because I've never seen this particular variant, which just seems like it makes the '-' and '+' characters legal in local variable names. What I'm used to from other 8-bit assemblers, particularly 6502 assemblers is this kind of syntax ... Kick Assembler also supports multi labels, which are labels that can be declared more than once. These are useful to prevent name conflicts between labels. A multi label starts with a ‘!’ and when your reference it you have to end with a ‘+’ to refer to the next multi label or ‘-‘ to refer to the previous multi label:
ldx #100 !loop: inc $d020 dex bne !loop- // Jumps to the previous instance of !loop ldx #100 !loop: inc $d021 dex bne !loop- // Jumps to the previous instance of !loop
or
ldx #10 !loop: jmp !+ // Jumps over the two next nops to the ! label nop nop !: jmp !+ // Jumps over the two next nops to the ! label nop nop !: dex bne !loop- // Jumps to the previous !loop label
Applying more than one '+' or '-' will skip labels. E.g. '+++' will jump to the third label:
jmp !+++ // Jumps to the third '!' label !: nop !: nop !: // <- here!
Question ... is that the kind of syntax that you gentlemen were trying to add to PCEAS, or did you really just want to make the '+' and '-' characters legal in local symbol names? I ask because I'd like to add the "multi-label" kind of syntax to PCEAS, and having two completely different interpretations of those '+' and '-' label modifiers is going to be pretty confusing ... so I'm contemplating disabling the syntax that you added, if you're not actually using it.
|
|
|
Post by elmer on Nov 29, 2021 16:05:52 GMT
mooz Last year you added this change to PCEAS ... "pceas: local labels can now start with '@'". Did you want the '@' character to be usable anywhere within any kind of label, or was the idea to just use '@' as an alternative to '.' at the start of a label to signify local labels? I ask because the checkin comment implies the 2nd case, but the way that it is implemented results in the 1st case.
|
|
|
Post by dshadoff on Nov 29, 2021 16:26:23 GMT
I was aware of the dot-labels, being things which are local to a major label (and thus can be multiply-defined). As in: subrout: ... ... .lp: ...
In this case, ".lp" is *effectively* subrout.lp
I don't even understand what .- or .+++ could possibly be.
|
|
|
Post by elmer on Nov 29, 2021 17:26:10 GMT
I don't even understand what .- or .+++ could possibly be. Yep, I have absolutely no idea why you'd want the ability to use a '+' or a '-' in a label definition or, the way that it is currently implemented in PCEAS, a random sequence of '+' and '-' characters that can be *anywhere* within a local label. The "multi-label" that is described in that section of KickAssembler's manual is a bit different, and it does perform a useful function, although I still find it pretty ugly. It is (IMHO) a nasty thing to put into regular assembly-language code, especially when you already have local labels such as we have in PCEAS with '.', and now with Mooz's '@' ... but the multi-label syntax is a reasonable solution for macros and small code-snippets where you need a local label that is guaranteed to not conflict with any of the programmer's other labels. It is just an alternative syntax to PCEAS's "\@" parameter in macros, and it can be implemented internally in a similar fashion.
|
|
|
Post by turboxray on Nov 29, 2021 21:31:33 GMT
-, --, ---, and +, ++, +++, etc come from the C64 asm world. I'm not a fan of it. It works comparable to how other assemblers use it, except requiring the preceding '.', meaning that it's a local label. It gives the ability to use local labels without names, to quickly jump forwards or backwards (I guess a bunch of '-' and '+' stands out more than using a bunch of chars?). I regretted putting it into PCEAS a couple of months afterwards. Mooz didn't put it in tho, I did. I think mic and some other 65x coders asked about support for it (I don't remember, but at the time a bunch of 65x code/libs were being porting to PCE). Like I mentioned, it means you would need to add white space between the ANY local label and the - or + operator, which is really bad because whitespace shouldn't be used to tokenize anything. I'm perfectly fine with taking that support out (I don't ever use it - it obfuscates code IMO). I mean, it doesn't even work 100% exactly like it does on other assemblers that support it (i.e. scope and resetting local scope).
|
|
|
Post by gredler on Nov 29, 2021 22:13:43 GMT
because whitespace shouldn't be used to tokenize anything. I'm perfectly fine with taking that support out (I don't ever use it - it obfuscates code IMO). Python hates me because of my tendency to use tabs vs other team members spaces and that's about the only way I can relate this Glad to hear all of this progress on the low level programming fellers, thanks for your time on it.
|
|
|
Post by dshadoff on Nov 29, 2021 22:27:05 GMT
Uh, are you saying it's used as a "here" reference +/- an offset ? On Z-80 assembly I had seen that as $, and somewhere else (maybe 6809) as '.'
djnz $
or
jr .+5
So, that may explain '.' +/- offset, but what was this .+++ business ?
|
|
|
Post by elmer on Nov 29, 2021 23:37:38 GMT
I regretted putting it into PCEAS a couple of months afterwards. ... I'm perfectly fine with taking that support out (I don't ever use it - it obfuscates code IMO). OK, thanks, I'll nuke it! Python hates me because of my tendency to use tabs vs other team members spaces and that's about the only way I can relate this Haha ... yep, I just refuse to program in Python because of that lunacy with its use of white-space! Uh, are you saying it's used as a "here" reference +/- an offset ? Yes, you've got the right idea, but you're thinking of different units. Instead of "*" or ".", or "whatever-your-assembler-uses-for-the-current-PC", +/- a specific offset in terms of bytes ... the "multi-label" syntax is looking at the current location, and going forwards or backwards and looking for labels with the same name. So !loop- is looking for the previous label called !loop, and !loop-- is looking backwards to the !loop label before that one. !loop- !loop-- !loop--- !loop+ !loop++ !loop+++ ... are all just a count of how many previous, or subsequent, "!loop:" labels to skip over. It is a fairly-ugly syntax that becomes horribly-unreadable very quickly, but it was once-upon-a-time a common way to get over the lack of local labels, particularly when using macros. Since there are still a lot of strangely-designed assemblers out in the world, and since a lot of the best-practices of previous generations seem to be regularly forgotten, this syntax still survives, and there are good reasons why it would be useful to make PCEAS understand it.
|
|
pokun
Gun-headed
Posts: 85
Homebrew skills: HuC6280 assembly
|
Post by pokun on Dec 2, 2021 21:47:51 GMT
The "@" is commonly used for local labels in 65xx assemblers while still using "." for assembler directives like PCEAS does. I think either is fine, but since "@" is kind of annoying to type on Swedish keyboards (ALT Gr+2) I kind of prefer ".", directives are usually indented anyway so I don't think they are often confused for local labels. Here is what the ASM6 (which is exclusively using +/- for nameless labels) readme has to say about labels: I think they are nice and use them sometimes in smaller code snippets. ASM6 doesn't allow you to mix local and nameless labels though which is kind of annoying and makes them much less useful.
64TASS supports both the +/- style of nameless labels and the truly nameless (just a colon) labels and can mix properly with local labels which is one of many reasons I like it. It uses underscore for local labels though, kind of weird but easy to type.
|
|
|
Post by dshadoff on Dec 2, 2021 23:02:14 GMT
Ok, I understand the intent better now. (But I don’t like it)
Seems pretty fringe-ish…
|
|