vsmenon/start

start's Issues

Type issue with counters?

This IR:
method x@1:
method main@5: l1#-4:int
instr 1: enter 0
instr 2: nop
instr 3: wrl
instr 4: ret 0
instr 5: entrypc
instr 6: enter 4
instr 7: count 0
instr 8: count 10
instr 9: ret 0

produces some error when sorting keys to print out.
Class 'String' has no instance method '>'.

NoSuchMethodError : method not found: '>'
Receiver: "0"
Arguments: [10]
#0 Object.noSuchMethod (dart:core-patch/object_patch.dart:19:25)
#1 int.< (dart:core-patch/integers.dart:62:18)
#2 int.compareTo (dart:core-patch/integers.dart:107:14)
#3 Comparable.compare.compare (dart:core/comparable.dart:5:64)
#4 Sort.insertionSort_ (dart:_collection-dev/sort.dart:26:34)
#5 Sort._doSort (dart:_collection-dev/sort.dart:15:21)
#6 Sort.sort (dart:_collection-dev/sort.dart:5:12)
#7 IterableMixinWorkaround.sortList (dart:_collection-dev/iterable.dart:753:14)
#8 List.sort (dart:core-patch/growable_array.dart:262:37)
#9 execute (package:start/starti.dart:648:14)
#10 main (file:///home/darioush/git/start/bin/start.dart:45:26)

Therefore, I'm assuming there is some problem with the types.
changing instr 7 to be instr 7: count 00 magically solves the problem but I guess some type is being inferred incorrectly.

WriteLong() doesn't print anything if you never have a WriteLine()

If there's no WriteLine() in a program then the values output from WriteLong() will never be printed.

Document type information in IR.

The current writeup does not describe the type information embedded in the IR or how it is used.

The "var_base#12" form in IR is ambiguous and can lead to errors.

Currently, the start compiler uses appends "_base" or "_offset" to a variable in the IR to indicate how to interpret it. E.g.,

• x#8 resolves to *(FP+8)
• x_base#8 resolves to 8

This is ambiguous if the variable actually ends in "_base". E.g., the following code runs incorrectly in Start.

import 'stdio.dart';

void main() {
int int_base;

int_base = 10;
WriteLong(int_base);
WriteLine();
}

Document all IR opcodes

E.g., isnull is not described.

Bug in the Start EBNF?

Currently, the EBNF has Term = Factor {('*' | '/' | '&') Factor}.. I think the & is supposed to be a % based on the listed Start operators.

Invoking a function before it's declared in the source is broken.

This should not fail. It's bug in the parser.

void foo() {
bar();
}

void bar() {
WriteLong(42);
WriteLine();
}