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 Mappum 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

[Twisol]

@krasin, it looks like DCPU-16 assembler directives are going to start with a # rather than a .. Is there any way to make LLVM emit that instead?

[krasin]

@Twisol news to me! Could you please provide a reference? Sad, if true. :(

[Twisol]

@krasin: As far as I know, it's based on a leaked version of the 0x10c source. I don't really care to peruse it myself, but I was shown the simple assembly program that produces the blue display from Notch's screenshots, and it used #. It also fits with the known paste with a #macro for reading keys.

So no, I can't point you to the actual source, but it is consistent with what we've seen.

[krasin]

I think I know what screenshot are you talking about. Let me find it.

[krasin]

It originates from this tweet:

; Reading characters from the keyboard
; by Markus Persson

#macro nextkey(target) {
    push(i)
    set i,[keypointer]
    add i,0x9000
    set target,[i]
    ife target,0
        jmp end

    set [i],0
    add [keypointer], 1
    and [keypointer], 0xf
:end
    pop(i)
}

:keypointer
dat 0

So, the macros are going to start with #, but it's fine for macros to have different prefix than for .size or .text. See, for example, A comparison of GAS and NASM: NASM has %macro directive and "section .text" for [dot]directives.

So far, I don't see any inconsistencies with Notch's assembler.

[Twisol]

Yes, but the other source (which, as I mentioned, I didn't actually peruse myself) is the leaked 0x10c source. Here, I dug the relevant paste out of my history for you:

http://pastie.org/private/9raewofk9asszelcfayhw

You can see #include in there too. Both #macro and #include are assembler directives, so it seems rational to assume that # is the proper prefix.

[krasin]

So far, I don't see any technical argument for the assembler not to support both prefixes, since it does not create a confusion.

[Twisol]

S'up to mappum then. :)

[krasin]

@Twisol Thx for the reference. I have found these sources. Looking... (will not share the link in public, because it may be not be desirable by Notch)

[a1k0n]

i just wrote a tiny perl script to translate these from the llvm backend. you have to handle .byte and .word as well and turn them into DAT statements. we really need an actual assembler/linker to do it right, as well as a C runtime stub (crt0).

sub emit_dat {
  my ($dat) = @_;
  push @unflushed, $dat;
}

sub flush_dat {
  if(@unflushed > 0) {
    print "dat ".join(',', @unflushed)."\n";
    @unflushed = ();
  }
}

while(<>) {
  next if(/\.text/);
  next if(/\.comm/);
  next if(/\.globl/);
  next if(/\.section/); # todo: collect sections
  if(/\.byte\s+(\d+)/) {
    emit_dat($1);
    next;
  } elsif(/\.short\s+(\d+)/) {
    emit_dat($1);
    next;
  }
  flush_dat();
  s/\t/    /g;
  s/, #/, /;
  print;
}