Expose hvm_c and hvm_cu in lib.rs

[developedby]

For people who want to use HVM as a library, it would be useful to give access not only to the rust runtime, but to the C and CUDA runtimes as well.

I want to have this as an option in Bend so that we can provide users with a default HVM version that is guaranteed to work out of the box, removing the need to install HVM as an external dependency and making sure that users always have one option of HVM that is compatible with their version of Bend.

[edusporto]

Something like what I did in the interop branch can be used to do this:

HVM/src/main.rs

Lines 84 to 90 in 0e9c596

	unsafe {
	let layout = alloc::Layout::new::<interop::NetC>();
	let net_ptr = alloc::alloc(layout) as *mut interop::NetC;
	hvm_c(data.as_mut_ptr() as *mut u32, net_ptr, run_io);
	// hvm_c(data.as_mut_ptr() as *mut u32, std::ptr::null(), run_io);
	alloc::dealloc(net_ptr as *mut u8, layout);
	}

net_ptr can then be read back into a Rust Net which could then be used as a library directly, without having to call hvm as a subprocess and read its stdout output.

I changed the original read back function to take an abstract NetReadback, which currently already works for the net coming from C and would take a bit more effort to work with the CUDA implementation.

HVM/src/ast.rs

Line 399 in 0e9c596

pub fn readback<N: interop::NetReadback>(net: &N, book: &hvm::Book) -> Option<Net> {

HVM/src/interop.rs

Lines 9 to 12 in 0e9c596

	pub trait NetReadback {
	fn enter(&self, var: Port) -> Port;
	fn node_load(&self, loc: usize) -> Pair;
	}

Is this an appropriate solution to this issue or are you looking for something else?

[developedby]

Yes, except that hvm_c shouldn't print in that case. Otherwise I'd still need to call it as a subprocess to be able to intercept it's output (which is not that much of a problem)