ASM502 - a new 6502 assembler.. (WIP)

[D-Type]

Here are some 6502 C compilers benchmarks:
https://gglabs.us/node/2293

Not mentioned is Oscar64, but the author tested it himself, 3 run each, with the following results. It's on Github, maybe check it out?

1 crc8
1.2
1.2
1.2

2 crc16
1.8
1.7
1.7

3 crc32
3
3
3

4 sieve
13.1
12.7
12.8

5 sieve bit
20.3
16.6
16.6

6 pi
82
82.8
82

7 fact
193.1
192.9
193

8 pow
4.4
4.4
3.9

9 puff2
12.6
12.3
8.6

10 aes256
18.7
18.6
16.7

[pixel]

SmallC with 6502 backend using assembly macros but with no optimization whatsoever.

[Merytsetesh]

You're right. There are enough assemblers nobody uses already.

Like mine!

[pixel]

Pfff. Beginners.

My 6502 assembler https://github.com/SvenMichaelKlose/TMA ... ES/GENESIS
written with my self-hosting x86 assembler https://github.com/SvenMichaelKlose/TMA.



EDIT: Just remembered my first 8086 assembler: it was written in gwbasic on an IBM-XT. The "assembler" analysed the output of the 'debug' to get the addresses of labels. Multi-pass until nothing changed. An act of desperation in times when you lost your popularity within a heartbeat showing up at home with a modem. Unfortunately its lost.

[orac81]

I would love if someone made a small assembler like ASM502 for the ARM, targeting the pi, android, Arduino, blue pill etc, so you didn't have to run an SDK full of bugs taking a gigabyte or more..

Just build GAS for ARM? For all those modern CPUs it really doesn't make a lot of sense to make a custom assembler - GAS will support them anyway

Fair enough I suppose. I never really got on with GAS on x86, and used NASM instead. The SDK on the blue-pill/arduino is really annoying - the tool for uploading the binaries is just a few K, yet the SDK is enormous, slow and buggy..


As for optimisations, C compiler etc - yes its really the job of the high level language although an assembler could do some of it. It would have to be possible to tell the asm not to optimise in certain places with a macro directive. A high level language is the best place for it because it has far more information - the scope of code and variables, the location of loop end points etc.

Back when writing ASM502 I was looking at Small-C, etc - in the end I started writing my own C compiler (x86, but intending to end up 6502). it is (of course) not complete. If I recall, when experimenting, the Small-C type compilers often seem to convert byte-arithmetic to 16 bits (via virtual ZP registers) for work, converting back to BYTE at the end - which is very inefficient.

Recognising the "static" keyword properly for both vars and subroutines can help - since we would not then need to push everything onto the emulated stack, which is slow on the 6502. I did also think of having one true BYTE register variable available - mapping to X reg. A lot more use of ZP for secondary register vars could help - cc65 didnt seem to use so many as are available if one just uses all of BASIC var space.

I did start thinking in terms of pattern recognition within the intemediate code, so for example

#define VDU 0x1e00 /* C64 0x0400 etc */
void showcharset ()
{
register BYTE x;
x=0;
do {
*(VDU+x) = x;
x++;
} while (x);
}

the compiler could pick out the larger pattern and generate..

VDU = $1e00

showcharset:
ldx # 0
loop01:
txa
sta VDU,x
inx
bne loop01
rts

Of course thinking it and actually doing it are very different things!

[orac81]

Here is the binary for the C64 version of ASM502.

asm502-114-c64.zip

(7.1 KiB) Downloaded 4 times

extract this and run asm502-114-c64.prg on your c64 emulator.
When you run (with no command line obviously) ASM502 asks for the Source file - type ASMIN.S, then leave Dest file blank.
It will run through and generate the listing file.
But note - source files must be converted to upper case. As I said above, ASM502 just allocates a block of memory for the whole source file, then compiles for RAM. For restricted memory platforms it would be much better to compile old-school line-by-line. I intend to implement this on a future version.
A 32k VIC20 version should work the same as this C64 version - again a version that works line by line would be needed.

Ultimately its a sort of demo - really I expect most people are going to code on a PC..

[groepaz]

the Small-C type compilers often seem to convert byte-arithmetic to 16 bits (via virtual ZP registers) for work, converting back to BYTE at the end - which is very inefficient.

One reason for that are the integer promotion rules of C though. I'd expect most c-compilers doing this actually - just the more advanced ones will remove the 16bit operations again during optimizing stages.

[Mike]

I did start thinking in terms of pattern recognition within the intemediate code, so for example [...]

Except it does not show the character set but merely clears the screen, that one in a post of mine dating from 2016 is actually the same example as yours:

If you take the simple assignment statement "X=X+1", the higher language necessarily needs to assume, that X as variable is contained in some memory addresses. [...]

Code: Select all

1 X=0
2 POKE7680+X,32
3 POKE7933+X,32
4 X=X+1
5 IFX<253THEN2

It's difficult to imagine, how a [...] compiler is supposed to infer, that it is sufficient to hold X in a CPU register! The whole processing of the longer paragraph above just collapses into a single instruction in machine language: INX!

Code: Select all

 LDX #0
 LDA #32
.loop
 STA $1E00,X
 STA $1EFD,X
 INX
 CPX #$FD
 BCC loop

... where "X=X+1" either incurs the full overhead of retrieving the value stored in X, adding 1 and storing the value to X again ... or can simply execute an INX instruction.

To be clear about this: If I need to explicitly tell the compiler that it should keep a value in a register, then I can quite as well write the routine in machine code myself. For me, the most appealing use case for compiled code on the 65xx is extensive business logic or I/O bound stuff which either is too boring, too complex or too time consuming implementation-wise for hand-written machine code. In the extreme case, even compiling that stuff need not be necessary: often enough a good blend of interpreted BASIC and a few support machine code routines is entirely sufficient to get the job done.