DCPU-16
DCPU-16 copied to clipboard
Don't fail on .text/.size/.align/.globl
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
@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?
@Twisol news to me! Could you please provide a reference? Sad, if true. :(
@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.
I think I know what screenshot are you talking about. Let me find it.
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.
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.
So far, I don't see any technical argument for the assembler not to support both prefixes, since it does not create a confusion.
S'up to mappum then. :)
@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)
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;
}