moroso / compiler Goto Github PK

The path is relative to the current directory.

Taking programs on stdin and writing binaries (or error messages!) to stdout isn't exactly optimal.

Right now, in code like

let i: u32 = 0;
{
  let i: u32 = 1;
}

there's no distinction between the inner and outer variable; they are both considered i.

When trying to define a constant pointer: const uart_base: *u32 = 0x80001000 as *u32;
I get the following error: Non-constant expression where constant expected.
This should be possible, as otherwise there's no way to initialize an arbitrary constant pointer.

It's pretty slow right now for targets based on the IR. We should make it faster!

One for expressions, and one for types.

gcc doesn't like it when you call functions it knows about like malloc and memcpy through a cast to a wrong type. It generates illegal opcodes.

fn main() -> u32 {
    let s: *u8 = 0 as *u8;
    let t = *(&s as u8 + 3);

    0
}

This is not well-typed, but it should print a type error. Instead it has an ICE:

task '<main>' failed at 'internal error: entered unreachable code', src/typechecker.rs:771
stack backtrace:
   1:     0x7f6bf0f0eda0 - rt::backtrace::imp::write::h2626651a2fc94766OLq
   2:     0x7f6bf0f11d90 - failure::on_fail::h03ed7212d81a2db7w7q
   3:     0x7f6bf0f21500 - unwind::begin_unwind_inner::hf47eb3d89161428crje
   4:     0x7f6bf0a00b80 - unwind::begin_unwind::h422749655183734816
   5:     0x7f6bf0a09e80 - typechecker::Typechecker<'a>::expr_to_ty::hc5ae88c33eb50683w6c
   6:     0x7f6bf0a16e30 - typechecker::Typechecker<'a>::block_to_ty::h4332730153b79d2enGd
   7:     0x7f6bf0a1fa10 - typechecker::Typechecker<'a>.Visitor::visit_item::closure.33696
   8:     0x7f6bf0a12240 - typechecker::Typechecker<'a>::with_generics::h2646355133747685451
   9:     0x7f6bf0a04e60 - typechecker::Typechecker<'a>.Visitor::visit_item::h6d83b4e8824299c5jee
  10:     0x7f6bf0a043c0 - typechecker::Typechecker<'a>::typecheck::h2648d77ca069b5b25Hc
  11:     0x7f6bf0b9d0a0 - mc::main::hd765d4b4ec89fe2eeZF
  12:     0x7f6bf0bf6fd0 - start::closure.8431
  13:     0x7f6bf0f22250 - rust_try_inner
  14:     0x7f6bf0f22240 - rust_try
  15:     0x7f6bf0f1f780 - unwind::try::h2d20ff3e4d5ebe36H7d
  16:     0x7f6bf0f1f550 - task::Task::run::h6c06266aca975e6cNdd
  17:     0x7f6bf0bf6d00 - start::h0795d18d071ca9e5soe
  18:     0x7f6bf0bf6c70 - lang_start::h1b3ea2e9962b8f3fLne
  19:     0x7f6bef573a50 - __libc_start_main
  20:     0x7f6bf09fb1f8 - <unknown>
  21:                0x0 - <unknown>

Pointer arithmetic is always measured in bytes, which is wrong. This is pretty critical for the kernel.

Taking the address of a function seems to be broken, and probably others, too.

Supporting +=, |=, etc would be nice. Probably follow rust and don't have ++/--.

The result of && expressions seems to always be true?

fn main() {
    if (false && false) {
        printf0_("u wot m8\n");
    }
}

prints "u wot m8"

The following code:

enum X<T> {
    Some(*T)
}

fn f<T>() -> *T {
    match *(null as *X<T>) {
        Some(x) => null as *T,
    }
}

fails with:

task '<main>' failed at 'Type is not fully constrained: <unconstrained>', src/target/ccross.rs:436

If the cast of null to *T is removed, it works.

Since we are using cpp as our preprocessor, we should be able to handle the line number directives that it outputs. This probably also means spans need to track file names.

Also refactor the way we deal with multiplication and division in codegen.

did I do it right?

const x: u8 = 1234;

fn main() -> u32 {
    x as u32
}

returns 1234, even though it's larger than a u8.

Mostly useful for debug spew for now.

Type probably should be u8? But could also have a char type.

Right now, the scheduler assumes that any two loads or any two stores can commute, which is not the case when the memory addresses are the same. It should be updated with stricter rules, and then re-enabled.

The purpose of this would be so that the assembler and simulator could cross-check each other: the simulator would decode instructions, output them in asm, and the assembler would parse and re-encode them. If the encodings don't match, it would likely indicate a problem in either the decoder or assembler.

Is more or less necessary for future development

Yeah.

Probably with a syntax like

for (let i: u32 = 6; i < 10; i += 1) { ... }

Accessing nonexistent struct elements ICEs

/*
  //*
*/

is treated as an unterminated multi-line comment, even though it shouldn't be.

joshua@bruges:~/projects/moroso/cpu/sim/cpu_sim$ ./cpu_sim -g --input mandelbrot.bin
OSOROM simulator starting
Reading from mandelbrot.bin
mdb@0x00000000> dis 0x3db0
      3d80 { nop; r4 <- *l(r30 + -0x4); nop; r30 <- r30 - 0x4; }
      3d90 { nop; r31 <- *l(r30 + -0x4); nop; r30 <- r30 - 0x4; }
      3da0 { B r31 + 0x10; }
 >    3db0 { r0 <- r0 *s r1; }
      3dc0 { r1 <- ovf; }
      3dd0 { *l(r2 + 0x0) <- r1; *l(r3 + 0x0) <- r0; }
      3de0 { B r31 + 0x10; }
      3df0 { nop; }

A write from 3dd0 could be moved to 3dc0, and then 3de0 could get merged with 3dd0.

Do what you must

We should have a bunch of unit tests, each testing a specific feature, instead of the more ad-hoc test programs we have right now.

at least, this is what I've observed. when I try to use an if-statement, I get "task '

I claim this is a bug

So like, I can write
printf2_("%d %d\n", p->i, -p->i);
and get
12 145297420

Right now a void function will still load a dummy value (5, in fact) into r0 on return.

^

I would like to have a break statement. For breaking out of loops and such :)

This way, we can ensure that compiler changes don't break anything in the kernel code (or at least, that nothing breaks enough that it no longer compiles).

I noticed that in the C output, a static array is not allocated onto the stack; I just get a pointer. Are we currently supporting static arrays and if not, do we intend to?

https://gist.github.com/amwatson/be9320ca4c24b078283f