Bytecode to bir #1472

rather than as calls that futz with MV. This can be used as a correctness condition, and it makes compiling to IR easier.

The unbound objects still cause all kinds of bad problems like segffaults that we absolutely do not want to be user-exposed.

This uniformly puts arguments on the VM stack before a call, VM or not, and saves a copy for multi-argument-form mv calls (the copy into the mv vector by pop-values). But my actual impetus is this structure makes the compilation to BIR easier, as all mv-calls are preceded by push/append-values, like how BIR requires a value-collect for any mv call. I had to increase the VM stack size to keep the build working, though. Bit worrying. The failure was when compiling the package definition for closer-mop, of all things.

This localizes the LLVM stuff in an entry point that accepts BIR, so if we produce BIR by some other means (e.g. from bytecode) we can reuse said stuff.

Still needs work, but it's functional.

If we need to test bytecodeness, we can just look at the type of the simple fun.

this makes setq a little less ridiculous to generate - we just use a stack spot instead of a local variable. This will reduce the number of local variables needed by some functions. Also makes things a little easier on bytecode-to-bir. It was screwing things up in that the temporary variable was conflated with earlier bound variables, which caused problems when the variable was closed over.

I will be adding more for the sake of further compilation, and this will make that easier. It also makes it possible to assert that the debug infos are in order (i.e. their START indices are nondecreasing) which is very convenient for the compiler and debugger.

Doing optional variables etc is going to be annoying

FLET might need a little more work

The bytecode compiler will have to keep track of optimize declarations for the btb compiler.

christ, i am stupid sometimes

This cuts down on pointless annotations.

By generation, and also in LTV FASLs

not gonna lie, this code is kind of ugly.

No longer necessary given the variable annotations and DUP.

Functions being relocated means that just generating the debug infos all in the same module vector as you go can result in non monotonic positions.

This is a pretty messy solution. drop-mv never actually needs to be executed, but it lets the compiler treat unconditional jumps as not happening for the purpose of compiling unreachable code correctly. FIX ME

without the notnilp it always returns true, which screws a few things up. durr

The more important intent of this is to store information about PHIs to simplify the btb compiler.

It does not seem to be used anywhere. It adds extra memory to the threads which is then never used, since those threads never even run Lisp code. Running the constructors can also be complicated and is again unnecessary.

Having a large array inside the VirtualMachine (and thus the ThreadLocalState) seems to crash the linker on Mac. It's also just sort of wonky. Probably ideally we'd have a more sophisticated setup here with mmap and guard pages and growth and yada yada, but this works ok. There is a definite suboptimality in allocating the entire max stack size all at once, but it's not _too_ big so maybe it's ok. It also means that the GC will walk the entire stack for pointers, including the inactive part, but Boehm is probably not capable of doing something more complex anyway. Or if it is it's wizardry.

This was apparently used for parallel linking at some point but was dummied out for mysterious reasons. Even without that, I suspect that the thread pool wouldn't need to be global.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bytecode to bir #1472

Bytecode to bir #1472

Commits on Jul 31, 2023