Track instruction source location to improve errors

[HParker]

This adds metadata constructed in the assembler and passed to the VM which provides information about instructions that can be used to improve error messages with line and column info.

Open to all feedback including, "This is not a feature UVM is looking for."

I think this could open the door to tracking additional information statically such as stack effects of an instruct etc. Do let me know if there is a more canonical way to track this kind of information.

Let me know what you think and if this is something I should pursue more.

[maximecb]

This seems useful and has been requested by another user.

Only comment I have would be, could you rename meta to op_meta, because eventually there's going to be program-level metadata as well.

[maximecb]

Hey @HParker .

I refactored UVM to support multithreading. As part of this I also made some small changes to the assembler. It now returns a Program struct (defined in program.rs).

Could you help me resolve the conflicts in this PR so we can merge it? :)

[HParker]

Ah great! excited to try it out! I haven't had time to invest, so for now I'll close and reopen after exploring the new code.

in the meantime, if you have a different solution or idea, feel free to go a different direction. :)

[maximecb]

in the meantime, if you have a different solution or idea, feel free to go a different direction. :)

Sure well I think this PR is a good idea. Makes debugging easier. Important to make UVM approachable to newcomers.

exploring the new code

It's not too different. I added primitives like thread_spawn and thread_join.

There are no more callbacks for the UI. Instead you call window_poll_event or without_wait_event (blocking). I updated most of the example programs accordingly.

Next I will add some thread-local variables, which will be necessary to implement C stack allocation for structs and arrays. At the moment if two threads stack allocate it won't work correctly.

I also need to add some primitives for atomic loads and stores. Right now there are no synchronization primitives. It would technically still be feasible to implement something like a parallel raytracer or to use a background thread for audio rendering where the audio thread reads control parameters from memory, but atomics will be needed to implement locking for more complex programs... Right now there is no way to implement a thread-safe message queue for example. I need to read more about atomics because I don't fully get all the subtleties yet.