Implement POPCNT/LZCNT/TZCNT #131

soc · 2020-01-07T17:40:26Z

Implements the three examples from #117.

dinfuehr · 2020-01-08T18:15:50Z

Already looks really good 👍 There can't miss much, I can help you out here - although probably not before the weekend.

dora/src/masm/x64.rs

dinfuehr · 2020-01-13T17:03:02Z

I will try to take a look the next few days. Can you please rebase it to master?

I suppose there is something wrong with the encoding. Did you try --emit-asm to see whether it prints the instruction you intend?

dinfuehr · 2020-01-17T22:21:24Z

Works on my Macbook. tester.rb doesn't support this right now, but you can just add a puts statement into the run_test method to print stdout/stderr.

I fear that we might have to introduce some form of check and fallback for this...

soc · 2020-01-22T23:28:01Z

dora/src/semck/prelude.rs

@@ -439,7 +456,7 @@ fn internal_method<'ast>(vm: &mut VM<'ast>, clsid: ClassId, name: &str, kind: Fc
        let mtd = vm.fcts.idx(mid);
        let mut mtd = mtd.write();

-        if mtd.name == name && mtd.internal {
+        if mtd.name == name {
            mtd.kind = kind;
            mtd.internal_resolved = true;


Should we set mtd.internal = true here too?

It is true if the function is marked @internal, so I wouldn't set it here. I am wondering about replacing kind here though: This means that the source of the function is never typechecked if the instruction is supported. You could write anything parsable in there and Dora will happily run without failures as long as the assembly instruction is available. I think we should store the intrinsic not in kind but in a separate new field, e.g. intrinsic: Option<Intrinsic> in vm::Fct. This ensures that the function is always typechecked. In baseline::codegen::get_intrinsic we first check kind of the function and if that is not an intrinsic already also the intrinsic field.

This function internal_method wouldn't need to change at all, we would add another function e.g. conditional_intrinsic_method which sets intrinsic instead of kind and is used for optional/conditional intrinsics.

Wouldn't it be cleaner to run typeck::check before we are adding the internal methods?

Agreed on optional intrinsic – but maybe it makes sense to have both the source code fct and the intrinsic marker as optional fields, such that all combinations can be represented faithfully?

EDIT: I moved prelude::internal_functions(vm) after typeck::check and verified that

the methods get typechecked in every case

the right implementation gets chosen

I am still not convinced that replacing kind is the way to go - but since I can't name an example where we need it in the runtime, we can do this.

dinfuehr

Great work! Pretty cool that with this PR we also have some infrastructure to query cpu support. I have proposed a few minor changes.

dora/Cargo.toml

dora/src/semck/prelude.rs

dinfuehr · 2020-01-24T09:25:38Z

dora/src/semck/prelude.rs

@@ -439,7 +456,7 @@ fn internal_method<'ast>(vm: &mut VM<'ast>, clsid: ClassId, name: &str, kind: Fc
        let mtd = vm.fcts.idx(mid);
        let mut mtd = mtd.write();

-        if mtd.name == name && mtd.internal {
+        if mtd.name == name {
            mtd.kind = kind;
            mtd.internal_resolved = true;


It is true if the function is marked @internal, so I wouldn't set it here. I am wondering about replacing kind here though: This means that the source of the function is never typechecked if the instruction is supported. You could write anything parsable in there and Dora will happily run without failures as long as the assembly instruction is available. I think we should store the intrinsic not in kind but in a separate new field, e.g. intrinsic: Option<Intrinsic> in vm::Fct. This ensures that the function is always typechecked. In baseline::codegen::get_intrinsic we first check kind of the function and if that is not an intrinsic already also the intrinsic field.

This function internal_method wouldn't need to change at all, we would add another function e.g. conditional_intrinsic_method which sets intrinsic instead of kind and is used for optional/conditional intrinsics.

soc · 2020-01-26T23:02:37Z

@dinfuehr Do you think this is good to go as it is now?

soc · 2020-01-26T23:04:26Z

dora/stdlib/Int.dora

@@ -42,6 +42,43 @@
  @internal fun unaryMinus() -> Int;
  @internal fun not() -> Int;

+  @internal fun countZeroBits() -> Int = self.not().countOneBits();
+  @internal fun countOneBits() -> Int {


The change in internalck now allows marking methods and functions with implementations as internal.

I think this is good because it makes it easier to see where some intrinsic could come into play.

soc · 2020-01-26T23:07:50Z

dora/src/semck.rs

@@ -155,7 +156,7 @@ fn internalck<'ast>(vm: &VM<'ast>) {
            let method = vm.fcts.idx(*method);
            let method = method.read();

-            if method.internal && !method.internal_resolved {
+            if method.internal && !method.internal_resolved && method.kind.is_definition() {


This change means that having @internal, but not having decided to use an intrinsic is now only considered to be a problem if we don't have an implementation in the source code.

soc · 2020-01-28T00:16:09Z

@dinfuehr is this good to go?

dora/src/semck.rs

dinfuehr · 2020-01-29T21:10:32Z

Thanks!

soc · 2020-01-29T21:45:21Z

Thank you too!