dcraftbg/sopl

A compiled, low level language

sopl's Issues

Result doesn't work for externals

Cause

Whilst the issue was partially fixed in the newest patches of 0.16.4A, it still doesn't work for 32 bit, and causes the program to generate invalid assembly -> result of the fact that all functions have a prefix '_' in 32 bit, however that isn't supported in the getting of result.

How to recreate the issue

The name example name.spl is the simplest one as it relys on malloc as an external. But just in case I update it:

include "../libs/libc/stdio.spl"
include "../libs/libc/stdlib.spl"
include "../libs/strlib/strlib.spl"
const NAMELEN = 50l;
func main() {
    let name: *char;
    name = malloc(NAMELEN);
    strset(name, NAMELEN, 0);
    printf("What is your name? ");
    gets(name);
    printf("Hello %s!",name);
    free(name)
}

Release mode doesn't check for strings passed as arguments

Cause

This issue happens because Release doesn't take into account arguments, only sets. That means that when you call a function with a string as an argument it won't get accounted for by the compiler, meaning it will generate invalid nasm assembly.

How to recreate the issue

A really simple recreation of it is Hello World:

include "libc/stdio.spl"
func main(){
   printf("Hello Wold!");
}

Setting value pointed to, with a result of a function call, may cause a crash

Cause

Mostly due to the fact that the SOPL compiler assumes that rsi is not going to be modified during the evaluation of the expression, and so when that does happen it causes unexpected behaviour

How to recreate the issue

A basic example is something like this:

func foo(: int) {
   RSI = 5;
   return 0;
}
func main() {
   let bar: [int,5];
   *bar = foo();
}

The specific issue with the generated assembly are these lines:

mov rsi, qword [bar]
call foo
mov dword [rsi], eax

This is also due to the fact that SOPL assumes that no matter what, functions always don't change specific registers

Long data type does not work in 32 bit mode and causes invalid nasm assembly to be generated

If you are compiling for 32 bit mode, don't use longs, otherwise your whole program is going to break and it won't generate valid nasm x86 assembly.

How to recreate the issue:

On a windows or linux machine provide the argument -arc win_x86/linux_x86. An example program could be:

func main(){
    let a: long = 5l;
    let b: long = 6l;
    let c: long = a+b;
}

[NOTE] If you are using longs throughout your code, try and replace them with size_t which will work on any platform you give it.

Fixing this issue will require implementation of 64 bit addition, subtraction, multiplication and division which is going to take a long time to implement by hand but is something that is planned to be added in the future (possibly).

Offsetting is wrong even for 64 bit

Cause

If you try running any program with arguments like long, long, char or something its going to break. This is probably due to this part of the compiler code:

if (offset-osize)%8 > 0 {
   offset-=8-(offset-osize)%8;
}

It only works for very specific cases, and even then it breaks.

How to recreate the issue

The easiest recreation would be to use a library like strlib. buffers from the examples breaks because of strset

include "../libs/strlib/strlib.spl"
include "../libs/libc/stdio.spl"
func main(){
    let name: [char, 500];
    strset(name, 500, 0);
    scanf("%s",name);
    printf("Hello: %s\n",name);
}