|
Post by elmer on Nov 2, 2021 1:23:23 GMT
Here's a question for y'all PCEAS assembly-language developers ...
I am tired of getting lost in long multi-page .if/.else/.endif conditionals, and the traditional work-around such as ...
.if MYVAR == 1 .else ; MYVAR == 1 .endif ; MYVAR == 1
Is both ugly, and it doesn't *really* help to verify problems with hanging or mismatched conditionals.
I propose add the ability to optionally (so it doesn't break existing code) follow .else and .endif with a repeat of the original expression, so ...
.if MYVAR == 1 .else MYVAR == 1 ; You can add a comment if you want it. .endif MYVAR == 1
I am not *currently* proposing to actually check the expression for anything other than syntax, and so I am not *yet* planning to implement a check for mismatched conditionals ... but it is one step towards that.
Does anyone have any comments/objections as to the wisdom of making this change?
|
|
|
Post by dshadoff on Nov 2, 2021 3:50:18 GMT
Frankly, I don't see a big difference between having the ';' and not having it...
However, when I add comments to an 'else', it doesn't repeat the original if conditional - because that branch has already been taken and repeating the expression could be confusing to the reader, who may not be me. I will either put the correct logical expression which describes the branch which follows, or more likely an English-language description of the objective (rather than mathematical expression)...
But having said all that, the only time I remember using a lot of .if/.else/.endif constructs was in startup.asm where it was intended to handle multiple configurations, where several stages of the startup required different code depending on the target configuration... and I don't think I want to handle multiple configurations again anytime soon (at least not for a hobby).
|
|
|
Post by elmer on Nov 2, 2021 14:40:49 GMT
Frankly, I don't see a big difference between having the ';' and not having it... Beauty is in the eye of the beholder! Yeah, it's not a huge difference, and you can just continue to use ";" if you wish, the idea is to definitely not break existing code/habits. But we absolutely cannot expand PCEAS to check for mismatched conditionals without expanding the syntax to allow for *something* else on the line between the " .endif" and the " ; My comment". However, when I add comments to an 'else', it doesn't repeat the original if conditional - because that branch has already been taken and repeating the expression could be confusing to the reader, who may not be me. I will either put the correct logical expression which describes the branch which follows, or more likely an English-language description of the objective (rather than mathematical expression)... That is pretty-much how I was taught, too ... but it doesn't mean that I can't choose to learn an (optional) new syntax if it provides some concrete benefit. Unfortunately, I can't think of an easy way to check for mismatched conditionals if the expression itself is different to the original condition. If you find the concept of repeating the same expression on the .else to be repugnant, then you can always not put any expression at all, and put whatever you wish in a comment, just like you do now. But having said all that, the only time I remember using a lot of .if/.else/.endif constructs was in startup.asm where it was intended to handle multiple configurations, where several stages of the startup required different code depending on the target configuration... and I don't think I want to handle multiple configurations again anytime soon (at least not for a hobby). Yep I agree, and think that library code is probably the heaviest long-term user of conditionals, but I also find myself using them a lot short-term for commenting-out or choosing between different bits of work-in-progress code. I am trying to write a bunch of assembly-language examples and library code, in order to provide more help for newbie PCE assembly-language programmers to get started on the platform. As such, I find myself in exactly the same situation as you were decades ago when you were creating MagicKit, and I'm finding it similarly troublesome to avoid the use of too many newbie-confusing conditionals ... but I'm trying my best! The current problem is my joypad code, which has three different versions of the code to choose between ... 1) 2-button only (that doesn't get confused by a 6-button joypad, unlike the System Card code) 2) 6-button & 2-button (that doesn't get confused by a mouse, unlike pretty-much every game that I've seen) 3) mouse & 2-button (that doesn't get confused by a 6-button joypad, unlike most mouse games) Even more fun is that the *accurate* reading of mice requires that there is also code to detect whether a MultiTap is being used, or not.
|
|
|
Post by elmer on Nov 11, 2021 20:06:21 GMT
Change is a good thing,I like what I read in this thread,the future looks bright for pce dev. I think that the idea of turboxray writing some new library functions for HuC is going to be brilliant, and it is going to really help HuC developers create even-more-impressive games! Anyway, even though I haven't released a new build of HuC myself in a couple of years, that doesn't mean that nothing has been done to it. I am about to update the "whats.new" file in HuC with the changes since my previous build, and it seems like there are some developers here that might be interested. HuC changes ...---------------------- Add the option for "fastcall" pragmas to use a PCEAS macro instead of generating a subroutine call. ---------------------- Allow the initial SCD overlay program to be larger than 192KB. ---------------------- PCEAS changes ...---------------------- Allow C-style "==" as an alternative to "=" as a comparison operator. ---------------------- The bank/page/offset of the procedure trampolines can now be set during assembly, although changing the MPR that the procedures run in can still only be set on the command-line (i.e. with "-newproc"). This is useful for new ASM code, but it should also allow experienced HuC developers to get rid of the extra partially-used bank at the end of a ROM, and to put the trampolines into the CONST_BANK, which is usually mostly empty. ---------------------- Allow an optional expression after ".else" and ".endif" which, when present, is checked to make sure that it matches the previous ".if". This can make it easier to find problems with multi-page nested conditionals. ---------------------- Allow more data, and/or a comment, to appear after a string on a ".db" line. This has been broken for decades ... it is finally fixed! ---------------------- Add "-newproc" to run ".proc" code in MPR6 instead of MPR5. This is useful when a developer is not putting their permanent code in MPR6 (the way that HuC 3.xx currently does it). ---------------------- Add "-strip" to remove ".proc" code that is defined by not referenced during assembly. This is useful for creating library files that want to only include routines that are actually used by a developer. ---------------------- Add "-ipl" option to pre-fill PCEAS memory with the 4KB of a CD-ROM IPL. This makes it easy to use PCEAS to create a custom CD-ROM IPL that contains code to change how a CD loads its first program. ---------------------- Add "-trim" option to strip off the unused head and tail of a ROM. This is for writing out assembled-code that is not aligned to 8KB banks ... such as snippets of relocatable code, sector-aligned CD-ROM overlays, or whole programs (on the Atari). ---------------------- Local labels can now start with a '@'. ---------------------- Add the ability to read graphic files in ".BMP" format. ---------------------- Add ".dd" for generating 32-bit data values. ---------------------- ISOlink changes ...---------------------- Add a directory of the CD-ROM contents into the ".ISO" file's IPL sectors. This allows assembly-language CD developers to find out what is on the CD. N.B. ISOlink already patches directory information into the HuC ".OVL" files that are included in the ".ISO". ---------------------- Add the "-asm" option to stop ISOlink from patching ".OVL" files on the CD with HuC-specific data. This is critical for assembly-language CD developers, and for making changes to HuC in the future. ---------------------- Add the ability to use a customized IPL file on the ".ISO", or to specify new IPL boot parameters that replace HuC's normal boot parameters. This is useful for assembly-language CD developers, and for making changes to HuC in the future. ---------------------- New tools ...---------------------- Add "sym2inc" tool so that symbol files can be parsed to produce include files. This is useful for multi-stage builds, where later stages need to know the addresses of code or data from earlier stages. It can also be used to make writing relocatable code easier. ---------------------- Add "wav2vox" tool for ADPCM compressing audio files to use on a PCE (or PC-FX) CD-ROM. ----------------------
|
|
|
Post by turboxray on Nov 12, 2021 18:19:09 GMT
Allow more data, and/or a comment, to appear after a string on a ".db" line. This has been broken for decades ... it is finally fixed! This has been on my radar since forever, but it was only annoying once in a while. No idea why there would be a line length/limit to this. Made no sense haha.
|
|
|
Post by elmer on Nov 12, 2021 20:07:53 GMT
This has been on my radar since forever, but it was only annoying once in a while. No idea why there would be a line length/limit to this. Made no sense haha. Hahaha, yeah, same here ... I only got annoyed enough to fix it when I wanted my new assembly language example source to look pretty! It was just a simple parsing problem. The end-of-string wasn't handled in the same way that evaluate() was handling expressions. Anyway, more new stuff today ... I've altered PCEAS to stop changing _bank_base after the 1st pass of the assembly, because it was causing a change in symbols' bank numbers between passes, which was then stopping certain things from working on CD/SCD that you could get away with on HuCARD builds. Phew ... that was a long sentence! I've also changed the expression-handling, so that '*' (the program counter) is now treated as a fake-symbol instead of just a value, which means that you can now find out the current bank during assembly. For example ... my_file: incbin "file.zx0" my_addr: ds 0
; This already worked before, because the data is written in the 2nd pass.
db bank(my_file)
; These used to fail because the bank changed between passes.
my_bank = bank(my_addr) .bank bank(my_file) + 3 - _bank_base
; These used to fail because * was not a symbol.
db bank(*) next_bank = bank(*) + 1 .bank bank(*) + 1 - _bank_base
|
|
|
Post by dshadoff on Nov 13, 2021 0:20:09 GMT
Nice, many of these are things I’d like to use too ! I was kind of thinking about making ‘-raw’ the default and switching to require a command option for adding a header…
|
|
|
Post by elmer on Nov 13, 2021 17:19:45 GMT
I was kind of thinking about making ‘-raw’ the default and switching to require a command option for adding a header… Fine by me ... although you'd need to change HuC too, because I think that it sends "-raw" these days. I'm thinking of changing PCEAS ".include" so that it remembers which files have been included, and then it will skip an include if you try to include it again. IIRC, that is similar to how modern C compilers work, and it would be useful to have for writing modular library code, so that individual libraries could ".include" their dependecies without causing duplicate code/definitions that will break a build. We can't just use C-style ".ifdef" header guards on PCEAS, because the included files need to be processed on both passes. Do you think that this would cause any problems that I'm not thinking of?
|
|
|
Post by dshadoff on Nov 13, 2021 18:41:35 GMT
If there was actual code in the include files, that could become a problem. It's not such an uncommon thing to do - although including the same code twice... may be less common.
|
|
|
Post by elmer on Nov 13, 2021 20:14:28 GMT
If there was actual code in the include files, that could become a problem. Oh, that is easy to deal with ... you just clear the list of remembered files at the end of each pass. Yeah, the idea is definitely to define code in the include files, usually library functions written as .proc subroutines ... then PCEAS can strip out any unused functions in a particular library.
|
|
|
Post by Galahad on Nov 14, 2021 4:39:15 GMT
Anyway, even though I haven't released a new build of HuC myself in a couple of years, that doesn't mean that nothing has been done to it. I am about to update the "whats.new" file in HuC with the changes since my previous build, and it seems like there are some developers here that might be interested. Thanks elmer,appreciate the quick replies and speedy fixes.
|
|
|
Post by elmer on Nov 15, 2021 22:08:44 GMT
Here's another useful change that even current HuC users can benefit from! PCEAS now keeps track of the highest address used in each bank, and procedures can fit into usused space at the top of any bank, rather than just being put in new banks at the end of the ROM (or overlay). DK and Gredler will be happy with this comparison of an old build of their Catastrophy game ... *************************************************************************************************** Old PCEAS, .proc code at the end of the ROM ** New PCEAS, .proc code fills unused space *************************************************************************************************** USED/FREE ** USED/FREE ZP $2000-$2015 [ 22] 22/ 234 ** ZP $2000-$2015 [ 22] 22/ 234 BSS $2200-$2F44 [3397] 3397/4795 ** BSS $2200-$2F44 [3397] 3397/4795 ** BANK 0 Base Library 1 7049/1143 ** BANK 0 Base Library 1 7049/1143 CODE $E010-$FB8E [7039] ** CODE $E010-$FB8E [7039] CODE $FFF6-$FFFF [ 10] ** CODE $FFF6-$FFFF [ 10] BANK 1 Base Library 2/Font 5903/2289 ** BANK 1 Base Library 2/Font 8192/ 0 DATA $6000-$65FF [1536] ** DATA $6000-$65FF [1536] CODE $A600-$B70E [4367] ** CODE $A600-$BFFF [6656] BANK 2 PSG Driver 7892/ 300 ** BANK 2 PSG Driver 8161/ 31 CODE $C000-$C029 [ 42] ** CODE $C000-$C029 [ 42] CODE $C043-$DEEC [7850] ** CODE $C043-$DEEC [7850] ** CODE $BEED-$BFF9 [ 269] BANK 3 Constants 2328/5864 ** BANK 3 Constants 8190/ 2 DATA $4000-$4917 [2328] ** DATA $4000-$4917 [2328] ** CODE $A918-$BFFD [5862] BANK 4 User Program 200/7992 ** BANK 4 User Program 8189/ 3 DATA $6000-$60C7 [ 200] ** DATA $6000-$60C7 [ 200] ** CODE $A0C8-$BFFC [7989] BANK 5 8190/ 2 ** BANK 5 8190/ 2 DATA $8000-$9FFD [8190] ** DATA $8000-$9FFD [8190] BANK 6 8192/ 0 ** BANK 6 8192/ 0 DATA $A000-$BFFF [8192] ** DATA $A000-$BFFF [8192] ... ** ... BANK 3E 8192/ 0 ** BANK 3E 8192/ 0 DATA $A000-$BFFF [8192] ** DATA $A000-$BFFF [8192] BANK 3F 6079/2113 ** BANK 3F 8192/ 0 DATA $A000-$B7BE [6079] ** DATA $A000-$B7BE [6079] ** CODE $B7BF-$BFFF [2113] BANK 40 8192/ 0 ** BANK 40 8192/ 0 CODE $A000-$BFFF [8192] ** CODE $A000-$BFFF [8192] BANK 41 8192/ 0 ** BANK 41 8170/ 22 CODE $A000-$BFFF [8192] ** CODE $A000-$BFE9 [8170] ... ** ... BANK 63 8191/ 1 ** BANK 61 8176/ 16 CODE $A000-$BFFE [8191] ** CODE $A000-$BFEF [8176] BANK 64 4954/3238 ** BANK 62 2831/5361 CODE $A000-$B359 [4954] ** CODE $A000-$AB0E [2831] BANK 65 3420/4772 ** BANK 63 3366/4826 PROC $8000-$8D5B [3420] ** PROC $8000-$8D25 [3366] ---- ---- ** ---- ---- 789K 27K ** 789K 11K ** TOTAL SIZE = 816K ** TOTAL SIZE = 800K ***************************************************************************************************
That's a saving of 2 banks, just for using a new version of PCEAS! A 3rd bank could be saved by using PCEAS's new ability to move the procedure trampolines into the any bank, and so bank 63 could be merged with bank 62.
|
|
|
Post by dshadoff on Nov 15, 2021 23:23:18 GMT
Very nice !
|
|
|
Post by gredler on Nov 16, 2021 2:43:36 GMT
Incredible!
|
|
|
Post by spenoza on Nov 16, 2021 19:48:22 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?
|
|