- 1.5d (NO-RELEASE)
o New instruction/operand parser. Can handle instruction availability, depending on selected cpu-type, and optional operands in common code.
o Now using the faster djb2 hash table algorithm. Tuned hash table sizes for PPC, M68k and x86. Bigger symbol and macro hash tables.
o m68k: New optimization: DIVU/DIVS.L #x,Dn can be optimized into LSR/ASR when x is a power of 2 and between 2 and 256. Negative values are handled by appending a NEG.L. DIVU/DIVS.W #1 is supported for ColdFire ISA_B/C by MVZ.W. DIVS.W #-1 by using NEG.W first. The new option is called -opt-div.
o m68k: New optimization: ANDI.? #-1,<ea> is optimized to TST.? <ea>. ANDI.L #$ff/$ffff,Dn is optimized to MVZ.B/W Dn,Dn for ColdFire ISA_B/C.
o m68k: New optimizations: ORI #0,<ea> and EORI #0,<ea> are optimized to TST <ea>. AND #0,<ea> is optimized to CLR <ea>, when allowed.
o PPC: Reworked cpu selection.
o PPC: Reworked operand parser and evaluater. mfdec is now recognized.
o mot-syntax: PhxAss-compatibility mode allows blanks in operands.
o mot-syntax: Ignore AsmOne AUTO directive.
o mot-syntax: Although ignored, load, jumpptr and jumperr should accept non-constant expressions.
o oldstyle-syntax: For Z80 '&' is allowed as a hexadecimal constant prefix.

I've worked with Frank on the new optimizations. I was hoping to implement more including the division by a constant to multiplication, shift and add. Here are a few of my observations, ideas and opinions...

o Frank only wants to do fairly simple peephole optimizations in vasm. More complex optimizations and non-peephole optimizations may best be left to the compiler. That includes optimizations that need a trash register which is common on the 68k. The good news is that vasm is already the best 68k (and maybe CF now) optimizing assembler available. The other good news is that Frank may try and improve the 68k/CF code generation of vbcc.

o It might be worthwhile to name and document a 68k+ColdFire ISA if the N68k CPU is nearly ready and has CF instructions. I suggest a name of 68CFn where n is the number of the ISA revision and CF stands for "Cool Fusion" to avoid copyright/trademark infringement with "Cold Fire". "Cool" in English has a slang meaning of good/liked/hip while Fusion describes the combining of 68k and ColdFire. There is a web site with that name which caters to the "Cold Fusion" database and a book that refers to "Cold Fusion" the chemical process but no computer product by that name that I found. I think it would be good to have a more basic ISA for 68CF1 that other 68k processors would be more likely to adopt like the FPGA Arcade. Vasm and later vbcc could use this ISA designation rather than N68050v1 or similar.

o The 68k shift instruction that allows only 8 immediate shifts is very limiting and awkward when it comes to writing optimizations. Many peephole optimizations will never be possible in vasm because of this. Optimizations in vbcc are likely more difficult to write as well and more registers are needed. A 32 bit shift encoding that allows the full 31 immediate shifts and operated on any EA would be worthwhile IMO. Vasm could make the optimization to the shorter version for shifts of 8 or less.

o Please define in the ISA and allow muls.l EA,Dn:Dn and mulu.l EA,Dn:Dn to update Dn with upper 32 bits of the 64 bit product only (mulh) as previously talked about. This will make some immediate division to multiply possible in vasm and save a register in vbcc allowing this optimization to be used more often.

o The rems and remu ColdFire instructions have the same encoding as divsl.l and divul.l. This has a potential for problems when the CF instructions are enabled. A compiler or ColdFire linked code could generate this instruction and trash a register. I believe the options would be to flag rems and remu as an error, or perhaps better, define an unused bit in the div encoding that suppresses the quotient and map rems and remu (as aliases) to use it. It could be called divur.l and divsr.l (r for remainder) and would be useful as it would save a register when only the remainder is needed (it's already possible to suppress the remainder if not needed).

  This isn't a release version (1.5d) yet so it shouldn't be posted as news but testing and suggestions are welcome. What wiki?
 
  I was hoping to get some input and communication so we can keep development going. Vasm can already assemble ColdFire instructions and place in an Amiga Hunk executable when a CF CPU or ISA(s) (e.g. mcfv4=ISA_B) are selected. If we had a basic ISA with 68k and CF instructions, then it should be possible to enhance vasm to support it and start testing and debugging. How much longer before the N68050 soft CPU is up and running? Will it have basic CF support at the beginning?