todo.txt

lots of chgs were made to the raytracer code
to make it compatible with wasi.  no threads.
write to stdout instead of a file.  etc.

added a hack to use wasi_unstable regardless of
what the wasm requests.  seems to kinda work.
fix this for the new multiple references code
from llvm_stuff.

--

WebAssembly/WASI#21 -- environ get, extra null

use names of locals ?

for brotli compress, setting initial mem size really 
high doesn't reduce number of calls to grow mem.  :-(
in other words, the malloc implementation in wasi-sysroot/rust
doesn't seem to be able to make use of more memory that
the process already has.

mv profiler out of Wasi assembly

mv trace out of Wasi assembly

should probably lookup all references in a ns2.0 reference
assembly.  seems wrong to have any references looked up
in the assembly that the compiler happens to be running
in.  is this the NetStandard.Library nuget package?

are we taxing the JIT by having funcs with so many
locals?  probably not?

enclosing class is always named foo ?  not at the
compiler level, only as a default in temporary
test console apps.  use the module name from the
custom name section?

--

we could have multiple reference/support assemblies
if we knew a way to get clang to not always use "env".
or if we just did a mapping.  so maybe clang always
thinks everything is in env, but we know to look
in different places for certain things.

env should be just for stuff the compiler looks
for that is not in wasi, extra stuff beyond the
wasi platform, or experimental additions

--

fix binary writer to handle the custom name section

--

interested in possibilities to simplify memory
access for perf.

can store the mem base in a local if we know it
won't change.  that helps the JIT optimizer.

even better, what if the mem base were zero?
like if we could replace the memory allocator
and just return actual addresses?  but then we
probably have a 32/64 bit problem.

another possibility is to never realloc but
just add blocks.  so the memory wouldn't be
contiguous, but we would need to present it
as if it were, like virtual.  benefit would be
that nothing ever needs to move.  once you know
the address of something, it doesn't change.

--

statics/globals might be a problem.  what if we want
to run lots of webassembly programs in a single
process, all sandboxed?

--

wasi layer is not doing path resolution correctly.
for example, in remove_directory, the fd param
is not used, even though it is supposed to be the
directory at which path resolution starts.

technically, an fd is documented as a uint.  but
wasm doesn't really distinguish between i32 and u32
that much, so the lookups will actually fail if
we declare, for example, set_flags() with the second
param as ushort.

need tests for the Wasm binary reader.  probably with
sample files that came from other sources, like clang.

need tests for the WASI layer

hmmm.  the code that gets the preopened fds is
called only from the startup code, and since 
the sqlite lib build doesn't generate an entry 
point, that never happens, so the open call dies 
because the po map is not valid.

    call $__wasilibc_init_preopen
    call $__wasilibc_register_preopened_fd

    /wasi-sysroot/libc-bottom-half/headers/public/wasi/

are strings in the wasi api supposed to be zero
terminated?  case by case?

how does wasm represent a null pointer?  if everything
is an integer address offset from the base of memory.

failing 204 because wasi sysroot has formatting of long
double disabled

--

explicitly add /usr/lib/llvm-8/bin to the path

sqlite3 demo vfs is weak.  it doesn't even have locking.
need to use the regular vfs, but without pthreads.
and mmap.

--

instead of calling Marshal.Copy, use Cpblk

peverify shows lots of problems

f64/i64 reinterp causes peverify type problems?
bitconverter.

tests for bit shifts?

why do shifts get [found Long][expected Native Int]

need test for GrowMemory

--

currently, the memory section of the module is ignored.
if there is no memory import, one is defined, whether
the module had a memory section or not.  do we need 
a way to specify a module which has no memory at all?

do we need a way to use System.Math instead of the math
routines in wasi sysroot?

consider --import-memory, but currently when we target
WASI we just ignore memory import anyway

--

test min and max?

xunit theory instead of fact

some combinations of compare/BrIf could probably
be merged into CIL like Beq.  like a peephole
optimization.

stack cleanup around br and friends.  write failing
test cases for this.

need more tests of invalid wasm

it would be nice to throw even more specific exceptions
so the tests can be more precise in error cases

memory load/store operations are supposed to be
range-checked

should use the short form of more CIL instructions,
like Ldloc

consider possibility of just using int everywhere
a uint32 is used, because that's just how .NET
does things, with array indexes and such being
int instead of unsigned

--

want to eventually package this as a dotnet global tool

maybe we need a func to emit an expression for init cases, 
more limited

not sure how imported table makes sense

need some tests to verify read/write of the binary
format

--

hmmm.  consider system.reflection.metadata
instead of Cecil ?

--

how to deal with non-mut globals?

still some problems in roundtripping binary format,
might be important, not sure.  update:  did this get
fixed with the leb128 decode signed fix?

need consistency about whether to pass around
wrapped indexes or just the ints

consider using checked int operations in leb128 code

best practice for formatting fs, type annotations, colon

def and read and write and cecil could be in separate assemblies?

review naming of def record fields.  compare to spec.
and conventions, lower case, etc.

chg assembly write to use a stream ?