#82 Some bugfixes and a new proc family try

[Petr Mikše]

Hi,

I did some work last year to fix some gpasm issues I found. I also tried to add a new procs. But I have no more time so I am not able to finish it.

Petr

Corrections:
Bank number remains after conditional jump pseudo (bc, bz ...)
No syntax errors after #IF 0
No more segfaults if FILL(instr) is used and processor is not specified
Correct label value before FILL (instr),n
Macro "while" is not listed if noexpand is selected.
Checks against symbol type change.
Bug ticket 323

Added:
__IDLOCS ADDR,VAL for PIC14E processors
List CBLOCK values in PARTLY list mode
List CONSTANT values in PARTLY list mode
CBLOCK values are in coff file including variable size.
EQU doesn't set in coff file type T_UCHAR. As a consequence the user can select variable size while debugging in mpasmx.
Creates definition __STRICT_LEVEL
Macro dereferency works if WHILE directive is used in it, too.
Conditional assembly lists YES/NO value and a nesting level.
Variable may be listed in hexadecimal using #h(nn) or #H(nn) syntax.
Number of digits may be specified using v#9(nn) or h#9(nn) syntax.
No parser loop forever if constant is used in CBLOCK instead of identifier.
(But CBLOCK still doesn't work correctly with errorneous input.)
Directive #include works in macro, too.
Code generated by macro is listed in noexpand list mode.
Enabled label after column 1.
Warning is issued if numeric constant is out of range.
Evaluate is more similar to mpasm(x) version.
Warning is issued if skip instruction is used before multiword pseudo (BZ,...)
if MESSG directive is in column 1 the user warning is issued instead of message.
if ERROR directive is in column 1 the assembly will be ended immmediatelly
Warning is issued if access is to the non implemented bit using bit instruction. (read and write separately)
a new directive ";__GOODBITS"
Directive name starts with a semicolon so it is ignored by mpasm.
;__GOODBITS LABEL, implemented_bit_mask
;__GOODBITS LABEL, can_read_bit_mask, can_write_bit_mask
;__GOODBITS LABEL, can_read_bit_mask, can_set_bit_mask, can_clear_bit_mask
;__GOODBITS LABEL, 'n-rwcs01'
n implemented bit,

    -  unimplemented bit
    r  read only bit
    w  write only bit
    c  may be clear by software but set, is readable too
    s  may be set by software but clear, is readable too
    0  unimplemented, read as 0, should be maintained as ‘0’
    1  not implemented, read as '1'

Not finished yet:
Support for PIC 16-bit (18Fxxx) with 64 RAM banks and vectored interrupts processors
(pic18f57q43)

[Anonymous]

Hi,

I am testing your changes.
I’ve verified this behavior with a simple test case:

#IF 0
    bla bla bla
#ENDIF

LABEL:
    FILL (nop), 100
NEXT_LABEL:
    END

This works fine now (BTW, it might be a good idea to add this to the regression test folder to help verify future commits).

Regarding the rest of the changes:

I noticed some commented-out code that seems intended for testing only—perhaps it’s worth cleaning this up? I assume this is just "work in progress"? For example, in parse.y at line 228, there is a printf that looks like debug output.

I haven't fully reviewed all the changes yet, but I'm seeing a significant shift in gpasm behavior. I tested a more complex project (available here: https://github.com/dk2233/PicThrowDK) and encountered the following errors:

PicThrowDK/16f913/ds18b20_with_lcd$ make
gpasm -L -f -S0 -e ON -c main.asm
symbols.inc:50:Error[113] Symbol not previously defined: ".4000000"
symbols.inc:57:Error[113] Symbol not previously defined: ".16"
symbols.inc:58:Error[113] Symbol not previously defined: ".2"
main.asm:27:Error[113] Symbol not previously defined: ".32"
Error[181] Assembly failed with total of 4 errors.
make: *** [Makefile:14: main.o] Błąd 1

It seems gpasm can no longer properly parse values like .4000000 in EQU directives.

Given this, I don't think the PR is ready to be merged yet.
It might be better to split your work into phases: first, the changes that are obviously working well, and then a separate part for the others that require further review and testing.

Let me know what you think.
Regards
Daniel Kucharski

[Anonymous]

Hi Daniel,
thank you very much for testing it.
I have just solved the bug you found:

.. EQU .4000000

This is a valid directive in both mpasm and gpasm now.
It's almost impossible to divide the work according to the key you mentioned. It seems easier to finish all the unfinished work.
Regards
Petr Mikše

[daniel kucharski]

Hi,

I’ve been testing your changes using one of my projects (https://github.com/dk2233/PicThrowDK/tree/main/16f913/ds18b20_led_relocatable ) and I’ve found a few concerning regressions.

1. Unexpected Warning [205] for directives in column 1
   When compiling with your patch, I get multiple warnings for standard code layout:
   Warning[205] Found directive in column 1: "if"
   Warning[205] Found directive in column 1: "else"

In previous versions of GPASM (and historically in MPASM), placing directives like if, else, or endif in the first column has never been forbidden—in fact, it’s a common practice to distinguish them from indented instructions. Is this new behavior intentional? It adds a lot of noise to the build output.

1. endc without cblock - Error vs. Silent Success
   I noticed a change in how "unmatched" endc directives are handled:

In Current Trunk: An unmatched endc triggers a syntax error, which correctly stops the build.

With your patch: The build continues.

If endc is in the first column, it seems to be silently ignored or handled by a recovery rule that doesn't stop the process.

If there is a space before endc, it's treated as a label: Warning[207] Found label after column 1: "endc".

In my opinion, completing a build with an unmatched endc is dangerous. It might lead to corrupted memory maps without the user realizing something went wrong. Why was the "stop on syntax error" behavior replaced with this recovery rule?

Regards,
Daniel K

[Anonymous]

Hi Daniel,

Directives if/else/endif ARE forbidden in column 1 in MPASMX. An #if/#else/#endif form is enabled only. So gpasm works this way now too.

cblock implementation in gpasm was/is buggy and needs to rewrite.
For example, in previous gpasm versions, this code assembly is never finished:

processor   16f1939
var macro   name,addr,size
    cblock  addr
name:size
    endc
    endm
    var 0xab,0x22,1
    end

Hopefully I'll have some time to do something about it after Easter.

Regards,
Petr