Shop OBEX P1 Docs P2 Docs Learn Events
Macro Assembler for P1, P2 — Parallax Forums

Macro Assembler for P1, P2

jmgjmg Posts: 15,173
in Propeller 2
From another thread .. musings on Macro Assemblers, for P1 and P2 ...
Peter Jakacki wrote: »
Re assembler - I would love to see a macro-assembler for the Prop!

I'm just now digging into fasmg , which continues to impress, the more I find out..
fasmg is the generic any-mcu macro version of fasm.

fasmg is part script engine, part assembler, and it is truly powerful.
It is coded in fasm, and comes in at a stunning 48k exe
Seems to have multi pass, and a means for automatic dead code removal.
HEX and LST are created via more scripts....

Download fasmg with examples, is a compact 236k

https://flatassembler.net/docs.php?article=fasmg_manual
https://flatassembler.net/fasmg.zip

Parallax P8X32A thread I started, to get some tips on how to best drive fasmg.

https://board.flatassembler.net/topic.php?p=190617#190617



Comments

  • jmgjmg Posts: 15,173
    edited 2016-09-22 20:55
    Example of progress so far, mainly quick framework testing :
    Some web-help, and now Updated to include both IF_ Prefix and W Suffix handling.
    ; ~~~~~~~~~~~~~~ Now Expanded to support Suffix too.. ~~~~~~~~~~~~~~~~~

;web suggestion 
define NR SUFF -001b 
define WC SUFF 010b 
define WZ SUFF 100b 
define SUFF

gParC = 1111b ; default, globalV init

macro F_ZCDS? ParD*,S_Suffix*&  ; & for ParS and any suffix controls
   gZCR = 001b ; default
   match S =SUFF suffix, S_Suffix  ;splits S,
       ParS = S 
       local flags 
       iterate flag,suffix   ; comma delimited list 
           if flag >= 0 
               gZCR = gZCR or flag 
           else  ;NR 
               gZCR = gZCR and not -flag 
           end if 
       end iterate 
   else 
       ParS = S_Suffix 
   end match 
   gZCDS  = (gZCR shl 23) + gParC shl 18 + (ParD and 0x1ff) shl 9 + ParS and 0x1ff 
   gParC = 1111b ; restore global default, after use  
end macro  

;           ZCRi    
;XOR 011011 001i cccc ddddddddd sssssssss  
;    109876 5432 1098 765432109 876543210  
macro qXOR? ParD*,ParS*& ; ParC now global, ZCR via any suffix 
    F_ZCDS ParD,ParS     
    match #data, ParS  
        dd (011011_000_1b shl 22) + gZCDS  
    else    
        dd (011011_000_0b shl 22) + gZCDS  
    end match    
end macro 

; ~~~~~~~~~ Build 32 IF_ variants ~~~~~~~~~~~~    
iterate <Cond,wxyz>,\
ALWAYS,1111b,NEVER,0000b,E,1010b,NE,0101b,A,0001b,B,1100b,AE,0011b,BE,1110b,C,1100b,NC,0011b,\
Z,1010b,NZ,0101b,C_EQ_Z,1001b,C_NE_Z,0110b,C_AND_Z,1000b,C_AND_NZ,0100b,NC_AND_Z,0010b,NC_AND_NZ,0001b,\ 
C_OR_Z,1110b,C_OR_NZ,1101b,NC_OR_Z,1011b,NC_OR_NZ,0111b,Z_EQ_C,1001b,Z_NE_C,0110b,Z_AND_C,1000b,\  
Z_AND_NC,0010b,NZ_AND_C,0100b,NZ_AND_NC,0001b,Z_OR_C,1110b,Z_OR_NC,1011b,NZ_OR_C,1101b,NZ_OR_NC,0111b  
    macro qIF_#Cond? instruction&  
        gParC = wxyz ; apply CC value, now global
        instruction 
    end macro  
end iterate 

; ~~~~~~~~~ Test coverage ~~~~~~~~~~~~
qIF_Z      qXOR 0AH,#05H  WC       ;C field set    011
qIF_Z      qXOR 0AH,#05H  WZ       ;Z field set    101 
qIF_Z      qXOR 0AH,#05H  WZ,WC    ;ZC field set   111 
qIF_Z      qXOR 0AH,#05H  WC,WZ    ;ZC field set   111 
qIF_Z      qXOR 0AH,#05H  NR       ;R field clr    000
           qXOR 0AH,#05H           
           qXOR 0AH,#05H  WC   ; Fixed with  push iterate flag,suffix into G_CDS?        
qIF_ALWAYS qXOR 0AH,#05H 
qIF_ALWAYS qXOR 0AH,#05H WZ
qIF_ALWAYS qXOR 0AH,#05H WZ,WC
qIF_ALWAYS qXOR 0AH,#05H WZ,WC,NR

; field checks 
	dd	(001b shl 23)  ; default
	dd	(101b shl 23)  ; wz
	dd	(111b shl 23)  ; wz wc
	dd	(000b shl 23)  ; nr
  • cgraceycgracey Posts: 14,152
    Looks really neat, jmg. I wish I had time to learn about it right now.
  • jmgjmg Posts: 15,173
    cgracey wrote: »
    Looks really neat, jmg. I wish I had time to learn about it right now.

    So far it looks promising, the idea is to find a good Macro Assembler, so you can focus on other, more critical things instead...
  • Cluso99Cluso99 Posts: 18,069
    jmg,
    I would like to see a short program using just a couple of P1 instructions, and the results of the compilation to get a better feel for it.

    If the preliminaries look good, then there are probably enough of us to write macros for each instruction once we have a complete macro for one instruction (ie including labels, condcodes, etc).
  • Dave HeinDave Hein Posts: 6,347
    The P2 pointer syntax may be a bit of a challenge for the assembler. It will also be interesting to see if it can automatically figure out which JMP code to use under different conditions. And then there's the differences in hub versus cog addressing, and when to use relative addresses versus absolute addresses.
  • jmgjmg Posts: 15,173
    Cluso99 wrote: »
    jmg,
    I would like to see a short program using just a couple of P1 instructions, and the results of the compilation to get a better feel for it.

    If the preliminaries look good, then there are probably enough of us to write macros for each instruction once we have a complete macro for one instruction (ie including labels, condcodes, etc).

    The code above covers Immediate, and the condition code IF_ prefix, and ADD and SUB and will produce a binary file.
    Not sure about any endian issues yet ?

    I'm looking at suffix handling for WC,WZ,NR, and have a limited version of that working.
    Need some tips from a fasmg expert to merge the prefix & suffix code ...


  • jmgjmg Posts: 15,173
    edited 2016-09-22 21:05
    Cluso99 wrote: »
    jmg,
    I would like to see a short program using just a couple of P1 instructions, and the results of the compilation to get a better feel for it.
    With some help, I've now sorted suffix variants too, with white-space and updated post #2 with example test coverage.

    Speed checks :
    ; Listing ON -> 2 passes, 2.4 seconds, 16547 bytes, 266k LST
    ; Listing OFF -> 2 passes, 0.4 seconds, 16547 bytes, 80 byte LST

  • jmgjmg Posts: 15,173
    edited 2016-10-18 19:46
    more:
    fasmg can export .hex via hex.inc macros, but that's slow, and seems to interact with other macros.

    addit: New versions of Listing.inc and hex.inc followed this slow/interact report, and they are now (much) faster & interaction is fixed.
    see: https://board.flatassembler.net/topic.php?p=191119#191119


    Alternative HEX and DB outputs :
    Some web searching finds srec_cat

    Download https://sourceforge.net/projects/srecord/files/srecord-win32/
    then run as 
    srec_cat P8X32_PropMacros.bin -binary -o P8X32_PropMacros.hex -intel
    and srec_cat can also do this, which is an ASM syntax DB list variant. 
    srec_cat P8X32_PropMacros.bin -binary -o P8X32_PropMacros.DB -ASM 

(strangely, -ASM options seems to fail, but default decimal is tolerable.)

creates
; http://srecord.sourceforge.net/
        DB      251,247,35,246,253,251,35,246,37,38,128,255,40,128,102,253
...
        DB      111,3,14,60,111,3,14,60,111,3,14,60,111
; upper bound = 0x4088
; lower bound = 0x0000
; length =      0x4088

    which can be INCLUDED into OnePin MCU ASM source, and it will auto-append the P2 code, to the small loader stub.

  • jmgjmg Posts: 15,173
    I'll bump this Assembler thread, with an assembler comment from the now-closed thread...
    David Betz wrote:
    ....Yup. That's one of the main reasons I haven't done anything on P2 for quite some time. .I need the instruction set and particularly the instruction encodings to remain stable. I also need the assembler syntax to be stable. I don't want to spend time modifying GAS for P2 only to find that a new assembler syntax gets invented and people start complaining that GAS doesn't match PASM.

    but I think we already have 'GAS does not match PASM' problems ?
    This is more an opportunity to bring PASM more into line with other assemblers ?
  • David BetzDavid Betz Posts: 14,516
    jmg wrote: »
    I'll bump this Assembler thread, with an assembler comment from the now-closed thread...
    David Betz wrote:
    ....Yup. That's one of the main reasons I haven't done anything on P2 for quite some time. .I need the instruction set and particularly the instruction encodings to remain stable. I also need the assembler syntax to be stable. I don't want to spend time modifying GAS for P2 only to find that a new assembler syntax gets invented and people start complaining that GAS doesn't match PASM.

    but I think we already have 'GAS does not match PASM' problems ?
    This is more an opportunity to bring PASM more into line with other assemblers ?
    Yes, we already have those problems with the P1 version of GAS. I'd like to avoid that as much as possible with P2. It's a big pain to rewrite the instruction parsers inside of GAS. I already did it once for P2-hot and pretty much none of that code will transfer over so I don't want to have to write it more than once more.
Sign In or Register to comment.