Don't fail on .text/.size/.align/.globl

[krasin]

Hi there,

LLVM backend has to emit the instructions like:

:autoinit       ;;Init data stack register C
    SET I, SP
    SUB I, 256

:autostart
    JSR main
:autohalt SET PC, autohalt
    ; .file "/home/jookia/Programming/YADOS/main.c"
    .text
    .globl  main
    ; .align    2
:main
    SUB I, 2 ; The Notch order
    SET [I], 0 ; The Notch order
    SET A, 1337 ; The Notch order
    ADD I, 2 ; The Notch order
    SET PC, POP ; The Notch order

.text, .globl, .align, .size and may be a few others. It's possible to disable output of some of them (like .align), but disabling .text .globl breaks LLVM test suite and makes it impossible to develop.

In the long run, DCPU16 assemblers will likely support these directives, because they are there for a reason. Since there's no demand for proper support of these directives from the users, but there's demand to use Clang/LLVM and there's no technical possibility to avoid emitting them, I would kindly ask dcpu16py assembler to ignore lines with these directives.

These directives always match the regex like "[\s]*[.]globl", so it should be pretty easy to ignore such lines.

The full list of directives to ignore (for now) is:

.globl
.size
.text
.data
.align

[enkore]

You may also open a issue here, so that most assembler coders will notice. Probably its best to say, that assemblers should ignore .ANYTHING_THEY_DONT_KNOW for interoparability

[krasin]

@enkore, thanks for the suggestion.

I have filed this feature request to a number of DCPU16 assemblers (tracking bug), so, when the developers of these assemblers respond, I will understand, if this feature is perceived as useful or not. If it is, I will definitely file a proposal to make this behavior standard.

[enkore]

I talked to Jarvix (who kind of maintains the asm recommendation) and when I understood him right, he'll probably adds this.

[krasin]

deNULL DCPU-16 Assembler, Emulator & Disassembler has recently fixed the issue (it ignores lines with [dot]directives). It's now listed as DCPU16 assembler compatible with LLVM DCPU16 backend.

What's better is that the fix was a one-liner!