zig compiler - calling roc · compiler development

Stream: compiler development

Topic: zig compiler - calling roc

Brendan Hansknecht (Feb 02 2025 at 19:18):

I wanted to write this out to make sure we are all on the same page. This is especially important cause I know we want to change some of the platform calling convention to make things easier to work with. This does not need to all be done at once, but I think some of it is important to do from the start.

Firstly, and probably the most important (it may effect some of the IRs). All functions that roc generates will now have an implicit arg. The arg will be a constant reference to a record that contains all allocation related functions. This will make it much easier for platforms to control allocations with arenas and what not. One piece I am not sure of with this design, do lambdas capture this record or do they take it as an argument? There may be some weird edge cases here that platforms need to be careful around.

Note: Due to switching to static libraries instead of surgical linking, all other effects will stay the same as they are today. They will not need to be passed in on each call. They will just be linked as normal.

Second, we want to change the host and effect function allowed types. Essentially, the host must box all returned lambdas and type variables. Type variables are allowed to be passed to the host, but they are simply opaque boxes to the host (Like Box model which the host would see as Box {}). This removes any sort of variable sized data being passed to the host.

Third, and this is a longer term goal, we want to generate cffi functions that the host can use to interact with all roc primitives. These can be gc'd if the host doesn't use them, but we should generate functions for all types exposed to the host to make them easier to interact with. This will fundamentally work with glue to make interacting with roc types way easier. Instead of repeating the same logic that is rather complex in N different glue scripts, we just have to wrap a couple of functions and tell the host how many bytes a type is.

Richard Feldman (Feb 02 2025 at 19:38):

Brendan Hansknecht said:

One piece I am not sure of with this design, do lambdas capture this record or do they take it as an argument? There may be some weird edge cases here that platforms need to be careful around.

I don't think they should capture. if I'm the host and I run a chunk of Roc code, I always want the whole thing to run using the allocators I specified at the call site. Capturing them would remove that invariant, which definitely sounds undesirable! :big_smile:

Richard Feldman (Feb 02 2025 at 19:38):

but in general that all sounds right to me!

Brendan Hansknecht (Feb 02 2025 at 19:44):

The hard part is that the lambda may capture variables that were allocated with the allocator that created the lambda. Maybe types need to store the allocator they were created with, but I was hoping to avoid that.

Brendan Hansknecht (Feb 02 2025 at 19:45):

Also, if types store the allocator, should they migrate to a new allocator if they grow in a different roc function with a different new allocator.

Richard Feldman (Feb 02 2025 at 19:51):

I think it's best to let the host figure that out

Richard Feldman (Feb 02 2025 at 19:52):

like if the host is going to store returned closures and then use them again later, it's up to the host to make sure they're being used with the same allocator again

Richard Feldman (Feb 02 2025 at 19:54):

or at least with a compatible one, e.g. if the new one is told to deallocate an address it doesn't recognize, it knows to ask the previous allocator to deallocate it

Brendan Hansknecht (Feb 02 2025 at 19:55):

Ok, yeah that sounds fine. I guess worst case the host makes a linked list of allocators. I wonder if this will make it hard to clean up old arenas. Probably depends a lot on context. Worst case the arena would last until all lambdas are resolved

Richard Feldman (Feb 02 2025 at 23:51):

I wanted to mention it in this thread too:

we talked about simplifying the ABI by saying the host always passes exactly 3 pointers to the compiled Roc function:

pointer to the struct of function pointers
pointer to the memory where the return value will be written
pointer to the memory where the 1 arg is stored (we restrict exposed Roc functions to 1 arg, but of course that 1 arg can be a tuple etc.)

Richard Feldman (Feb 02 2025 at 23:51):

this means we don't need to deal with C ABI at all

Brendan Hansknecht (Feb 02 2025 at 23:55):

Yeah, that would free us from c call conv, but not from c abi in general (well, I guess glue just has to use c abi layouts to match roc's layout, so it does mostly avoid c abi too)

Brendan Hansknecht (Feb 02 2025 at 23:56):

Also, I think n args is fine.

Brendan Hansknecht (Feb 02 2025 at 23:56):

but yeah, each arg is passed by pointer to avoid abi for the most part

Brendan Hansknecht (Feb 02 2025 at 23:58):

That said, for the interpreter, it would take that and map it to having all args in a list and also a list of types for each arg.

Richard Feldman (Feb 02 2025 at 23:59):

I think if we did one pointer per arg, there would become (correct) folklore that it's better for perf if you just put everything in one arg

Richard Feldman (Feb 02 2025 at 23:59):

so I feel like we should just make that be how it works directly

Brendan Hansknecht (Feb 02 2025 at 23:59):

it's better for perf if you just put everything in one arg

Why would that be better perf?

Richard Feldman (Feb 03 2025 at 00:01):

if I'm passing four u16s, passing the four pointers will use way more memory than the four u16s themselves

Brendan Hansknecht (Feb 03 2025 at 00:01):

I don't think it would be consistently better or worse. The cost of putting them in one arg is making a big stack allocation and copying everything over. If in the platform they are all separate data, it is probably faster to pass them as separate pointers and avoid any copying of data.

Richard Feldman (Feb 03 2025 at 00:02):

fair

Richard Feldman (Feb 03 2025 at 00:02):

ok yeah maybe that's better just to make one less rule to think about

Brendan Hansknecht (Feb 03 2025 at 00:04):

Honestly, I don't think the platform to roc boundary will be in the hot loop generally speaking. If roc is doing that little, you probably don't want to dish out to roc at all. So I think any abi is probably fine.

Luke Boswell (Feb 03 2025 at 00:05):

Is it helpful to think about what would be nice for Go, or Swift, or other languages to work with?

Luke Boswell (Feb 03 2025 at 00:05):

I feel like C or Zig is easy to do anything... but if we stray to far from convention it may make it difficult for those other languages to call into roc

Richard Feldman (Feb 03 2025 at 00:07):

nah

Richard Feldman (Feb 03 2025 at 00:07):

don't think this should matter for them

Richard Feldman (Feb 03 2025 at 00:07):

they have to know how to pass pointers to things regardless

Luke Boswell (Feb 03 2025 at 00:07):

Also -- not sure if we've forgotten about it. But should we discuss hot-reloading or the ideas around that?

Richard Feldman (Feb 03 2025 at 00:08):

yeah! prob in its own thread?

Luke Boswell (Feb 03 2025 at 00:08):

Yeah, I'm not sure what to say though... other than "hey, anyone thought about hot-reloading?"

Brendan Hansknecht (Feb 03 2025 at 00:13):

Also, just to note, we are defining two different specs here. One for libroc and one for standard platform->roc calls.

Here is what I would propose:

LibRoc

A pointer to write the return data to
A pointer to write the return TypeSpec to
A record of function pointers (this must include all effects).
A slice of pointers (these are the args)
A slice of TypeSpec (this tells it the types of every arg)

Platform -> Roc standard FFI

A pointer to write the return data to
A record of function pointers (only allocators functions and roc_load)
N pointers, one for each arg.

The shim would map between those to formats. A standard host would only implement "Platform -> Roc standard FFI". A host directly consuming libroc would implement "LibRoc".

Richard Feldman (Feb 03 2025 at 00:14):

I'm not understanding the benefit of the typespec thing

Brendan Hansknecht (Feb 03 2025 at 00:16):

The interpreter will run solely using tagged data. You didn't want recursively tagged data like would be traditional if we made a RocObject that the interpreter used. Without that, we need a type spec so the interpret can understand the underlying data.

Richard Feldman (Feb 03 2025 at 00:17):

that's true inside the running interpreter, yes

Brendan Hansknecht (Feb 03 2025 at 00:17):

As a simple, if the interpreter calls List.len, it needs to know the element type of the list. This is required so it can decrement the refcount of the elements and free them.

Brendan Hansknecht (Feb 03 2025 at 00:18):

Yes, and if a platform is able to dynamically build up args to call into the interpreter, we want to make sure the args passed in are what the roc function expects

Brendan Hansknecht (Feb 03 2025 at 00:18):

Otherwise, we may blindly use the arg as the wrong type due to only trusting the roc source code and things would go very wrong.

Richard Feldman (Feb 03 2025 at 00:21):

the thing I'm missing is that the caller still has to get the ABI right

Richard Feldman (Feb 03 2025 at 00:21):

like if I give you a pointer to some bytes, and then I also give you a thing that says "hey the pointer to the bytes has this type"

Richard Feldman (Feb 03 2025 at 00:21):

and the type I'm giving you at runtime is always going to be the same type as the type you've statically declared you're expecting

Brendan Hansknecht (Feb 03 2025 at 00:23):

I think it doesn't matter much for the shim use case. The shim gets rid of this type safety anyway by using the static API matching what llvm will use

Richard Feldman (Feb 03 2025 at 00:23):

then the scenario where this helps is:

I gave you bytes that aren't the type you expect, even though you told me what you expect
however, I correctly described the bytes I was giving you
so I knew what type I was giving you, and although I statically had the information that you expected a different type, I missed that or something
therefore, this runtime check caught it and replaced UB with a crash

Brendan Hansknecht (Feb 03 2025 at 00:23):

For direct use of lib roc, more dynamic use cases should be possible

Richard Feldman (Feb 03 2025 at 00:23):

but in all cases we know statically what the expected type is

Richard Feldman (Feb 03 2025 at 00:24):

like there's no value of main.roc I can pass to it where I don't statically know what types are expected

Richard Feldman (Feb 03 2025 at 00:24):

I guess the scenario could be that I gave it the wrong main.roc maybe?

Brendan Hansknecht (Feb 03 2025 at 00:25):

Sure, I guess then libroc at least needs to expose a function to get the type spec and list of exposed functions in main.roc

Brendan Hansknecht (Feb 03 2025 at 00:26):

That anchors to main.roc as the source of truth and trusts the platform to follow the spec read from main.roc. this is more thinking about future libroc use cases than the current shim plans.

Brendan Hansknecht (Feb 03 2025 at 00:27):

Cause a platform could dynamically load a main.roc file and do something different depending on what is exposed by the main.roc file. A simple example would be supporting plugin versioning. Load main.roc, depending on the return function API, you know the plugin version to run with.

Brendan Hansknecht (Feb 03 2025 at 00:33):

Anyway, assuming the platform -> roc part looks fine, let's move the rest of this discussion over to the libroc thread. I think that dynamic use case is what needs to decide the API for it

Richard Feldman (Feb 03 2025 at 00:34):

I guess if the typespec is like a hash of the types, that's probably very quick?

Richard Feldman (Feb 03 2025 at 00:34):

as in, if it's just for validation

Richard Feldman (Feb 03 2025 at 00:35):

or perhaps it's a hash for quick validation plus an expanded version for more helpful error messages if the types disagree

Brendan Hansknecht (Feb 03 2025 at 00:41):

I imagined it as a tag union of a spec defining the type, but I really haven't thought through it in detail. For the full libroc use case, it needs to be enough information that the interpreter can call a dynamic function with type variables.

Richard Feldman (Feb 03 2025 at 00:42):

I think maybe something worth establishing (because I'm not sure if we're on the same page about it) is that the only benefit of passing a type spec is that it would allow for an extra runtime check which could either give an error or do nothing

Richard Feldman (Feb 03 2025 at 00:42):

like it wouldn't allow any useful amount of introspection, or performance (would be a slight perf downside but negligible if we pass a hash)

Richard Feldman (Feb 03 2025 at 00:42):

wouldn't be necessary for correctness, etc.

Richard Feldman (Feb 03 2025 at 00:43):

and a totally reasonable alternative design would be to just not do a typespec at all, and everything would work exactly the same way except that in the specific case where you have a correct typespec for what you're passing but that typespec doesn't line up with what main.roc expects, the typespec would have let you get a runtime error instead of UB

Richard Feldman (Feb 03 2025 at 00:44):

does that all sound right?

Brendan Hansknecht (Feb 03 2025 at 00:45):

The interpreter will just end up creating the type spec anyway if the platform doesn't. It will be required internally to run the interpretter. Let me put up an example.

Richard Feldman (Feb 03 2025 at 00:47):

oh for sure!

Richard Feldman (Feb 03 2025 at 00:47):

no disagreement there

Richard Feldman (Feb 03 2025 at 00:47):

I'm just talking about the specific question of whether the host should construct its own type spec and pass it to libroc

Brendan Hansknecht (Feb 03 2025 at 00:48):

In the default use case, the shim constructs the type spec

Richard Feldman (Feb 03 2025 at 00:48):

but of note, I'm saying the interpreter has to create its own typespec in either cae

Richard Feldman (Feb 03 2025 at 00:48):

*case

Richard Feldman (Feb 03 2025 at 00:48):

oh wait, are you thinking it doesn't do validation at the boundary?

Richard Feldman (Feb 03 2025 at 00:48):

like it just accepts whatever it was given as truth, and then starts interpreting on that, and if that results in a runtime type mismatch at some point, so be it?

Brendan Hansknecht (Feb 03 2025 at 00:51):

Ok, I feel like this just got mixed up do to talking about libroc and about standard roc calling.

Let me try to anchor it.

Normal platforms only see a single interface. That interface is:

Platform -> Roc standard FFI

A pointer to write the return data to

A record of function pointers (only allocators functions and roc_load)

N pointers, one for each arg.

That is all they see period. Anything libroc is an implementation detail and not exposed to the platform.

Brendan Hansknecht (Feb 03 2025 at 00:52):

The shim library will deal with whatever is required to map from that interface to libroc.

Brendan Hansknecht (Feb 03 2025 at 00:52):

Are we in agreement with this interface?

Richard Feldman (Feb 03 2025 at 00:54):

I agree that's the standard interface between for the host in a platform + application that's compiled into a single binary

Richard Feldman (Feb 03 2025 at 00:54):

but I don't think that libroc needs to necessarily be in any way different from that interface

Richard Feldman (Feb 03 2025 at 00:54):

we can choose to have it be different, but it's optional

Richard Feldman (Feb 03 2025 at 00:56):

in other words, libroc can expose a function which is exactly the same interface as :point_up: except for 3 extra arguments:

The path to main.roc
The function to go from a path to a .roc file to its source bytes
The name of the entrypoint function within main.roc that I want to call

Luke Boswell (Feb 03 2025 at 00:56):

only allocators functions and roc_load

roc_alloc/roc_dealloc/roc_realloc - allocators for roc to use
roc_panic - roc crashed.. here's what happened
roc_debug - here's a dbg thing for your information
roc_expect_failed - hey an expect failed, heres some information about that
roc_load -- give me the bytes for a file path

Richard Feldman (Feb 03 2025 at 00:56):

and then I just give it the arguments exactly as normal

Brendan Hansknecht (Feb 03 2025 at 00:56):

look at the last message in #compiler development > zig compiler - libroc exploration and lets move the conversation there. That is why libroc needs a different interface.

#compiler development > zig compiler - libroc exploration @ 💬

Richard Feldman (Feb 03 2025 at 01:02):

separate thought about calling roc in general

Richard Feldman (Feb 03 2025 at 01:02):

we have the rule that only Boxed closures can be sent to the host

Richard Feldman (Feb 03 2025 at 01:02):

and in the interpreter, all closures are boxed

Richard Feldman (Feb 03 2025 at 01:02):

I guess that means we have an extra layer of boxing on them

Brendan Hansknecht (Feb 03 2025 at 01:02):

A record of function pointers (only allocators functions and roc_load)

edit: I think this just needs to be the allocator functions. The rest can be linked in like normal effects.

Brendan Hansknecht (Feb 04 2025 at 22:06):

Edit to my edit. Given we want to support roc code as a shared library, we actually do want to require passing in all effects period. Forgot about this use case.

Otherwise you get into all of the rdynamic pain and into brittle code symbol code that may not even consistently work cross platform.

Luke Boswell (Feb 04 2025 at 22:08):

Can glue (in future) generate the full type for our struct that needs to be passed in? -- with all the allocators, and entry-points, and effects etc

So if I'm writing a platform in zig or rust for example, it's pretty hard to pass in the wrong things.

Brendan Hansknecht (Feb 04 2025 at 22:09):

Just a record of function pointers. Sounds doable.

Luke Boswell (Feb 04 2025 at 22:13):

I'm thinking of stubbing out roc glue to take a fake glue script, and generates some zig/rust/go/c (not sure which) glue for a test platform using the new calling roc shape.

Brendan Hansknecht (Feb 04 2025 at 22:14):

I would keep everything in zig for now.

Brendan Hansknecht (Feb 04 2025 at 22:15):

And sure, though I'm not sure how valuable having the cart this far before the horse is.

Brendan Hansknecht (Feb 04 2025 at 22:15):

For glue, maybe we should just focus on the roc side

Luke Boswell (Feb 04 2025 at 22:15):

We are going to the effort of engineering this thing top-down... it's all cart before horse

Brendan Hansknecht (Feb 04 2025 at 22:15):

It needs to be expanding to support telling about all of the effects and such

Brendan Hansknecht (Feb 04 2025 at 22:16):

Luke Boswell said:

We are going to the effort of engineering this thing top-down... it's all cart before horse

I think this is useful for broad strokes, but it often is just wrong for specific details that depend on an unknown implementation. So I would focus more on concrete API than on stubbing all the interfaces loosely

Brendan Hansknecht (Feb 04 2025 at 22:17):

I think a lot of these pieces will be easier to get right once with have a slim slice of the compiler from parser down to interpreter

Brendan Hansknecht (Feb 04 2025 at 22:18):

But don't let me stop your stubbing if you think it is useful

Luke Boswell (Feb 04 2025 at 22:19):

You have outlined a specific API above for calling roc. I am proposing making a test platform that uses this new convention, and stubbing out the roc side of things -- to see it all working together, even though our roc side hasn't been implemented yet.

Luke Boswell (Feb 04 2025 at 22:20):

I'm also particularly interested in validating the fully-embedded roc use cases, which is more covered in that libroc exploration thread.

Brendan Hansknecht (Feb 04 2025 at 22:23):

For fully embedded roc, I don't think this API is required. Or even recommended. You have direct access to roc internals. So you want a different API. I tried to mention the two apis above though.

Luke Boswell (Feb 04 2025 at 22:24):

My other reason, is I was hoping to figure out how to get our bundled lld linking thing working, so roc build produces an executable.

Luke Boswell (Feb 05 2025 at 06:06):

@Brendan Hansknecht and I have been cooking... we've put together a working prototype of roc build with an example platform, and a fake roc app.o object file.

All the files are sitting on this branch. We will probably migrate into the roc repo -- now that it's less of a hack. I've included some explanation and notes in the README in case that helps.

https://github.com/lukewilliamboswell/roc-platform-template-zig/tree/calling-roc

If you want to try it out...

$ zig build-obj host/app.zig
$ zig build-lib host/main.zig
$ zig build-exe app.o libmain.a
$ ./app
info: Running Roc APP
Hello

There are a few things different from the current way we do things, and we've tried to implement the ideal based on our previous design discussions.

Now would be a good time to discuss the API, and if there are ways we can improve things.

Luke Boswell (Feb 05 2025 at 06:09):

I wouldn't advise looking closely at host/app.zig -- it's a real hack and some scary internal things that would never be exposed to the general public.

It's better to look at platform/app.roc which is the example and pretend the compiler generated our app.o object file and linked it with the prebuilt-host libmain.a all behind the scenes.

Brendan Hansknecht (Feb 05 2025 at 06:26):

Two immediate painpoints I noticed (carry overs from the old api):

dealloc not having a size means that the allocator has to track the size. In the case of zig, this means we allocate an extra usize before every allocation to store the size.
Alignment is not useful cause zig only takes it as a comptime value (I guess you could manually toggle between all the alignments, but it isn't as nice). Also, in practice, everything will be aligned to 8 or 16, so no real gains.

Brendan Hansknecht (Feb 05 2025 at 06:28):

One silly thing I noticed:
Always using pointers means that a number of functions with trivial args or return types have ABIs that look really poor. Look at the string functions especially.

Jasper Woudenberg (Feb 05 2025 at 07:04):

The pain points I've ran into trying to write a Zig platform and using a Zig allocator for Roc memory allocation. For Zig platform code it'd be really nice if the roc allocation API were ziggier, saves quite a bit of work! I guess that comes at the cost of writing platforms in other languages, though it does seem like it might be easier to implement malloc on top of a zig allocator then the other way around.

Brendan Hansknecht (Feb 05 2025 at 07:12):

Yeah, I think We will always be anchoring to cffi. Looking at the new example, apparate from passing the size to dealloc, I'm not sure we could make it ziggier.

Brendan Hansknecht (Feb 05 2025 at 07:12):

We can't give it a comptime alignment cause cffi can't comptime

Brendan Hansknecht (Feb 05 2025 at 07:12):

You can directly use an arena or other zig allocator now.

Brendan Hansknecht (Feb 05 2025 at 07:13):

We give enough info for most of the calls....free is the only pain point I think.

Brendan Hansknecht (Feb 05 2025 at 07:19):

And I currently don't know how to solve free except my making every list and string allocation 4 to 8 bytes larger to store the size.

Instead with the example platform, we end up making all allocations 4 to 8 bytes larger (including recursive tags and boxes).

Note, with arena allocation, this extra size would go away.

When using an allocator that implicitly tracks the size, allocations are not made any larger at all.

Brendan Hansknecht (Feb 05 2025 at 07:20):

I wonder if we can somehow get some allocator internal info on size information and avoid this explicit tracking

Jasper Woudenberg (Feb 05 2025 at 07:28):

Ah, thanks for explaining, that makes a lot of sense.

I guess it's not so bad, we can write a Zig->Roc allocator helper once and then anyone writing a Zig platform can use that. Maybe it'd be the kind of thing to include in Luke's platform examples repo.

Brendan Hansknecht (Feb 05 2025 at 07:48):

Yeah, I think we could easily make something that wraps a zig allocator to make it track size. And as mentioned above for arenas and for allocators that already internally track size (if you can get access to the internals), you can avoid adding the size to the allocation.

Oskar Hahn (Feb 05 2025 at 13:14):

I have written one here:

https://github.com/ostcar/roc-aoc-platform/blob/main/host/RocAllocator.zig

It probably can be improved

Richard Feldman (Feb 05 2025 at 15:11):

over the years we've gone back and forth regarding whether it would be possible for Roc to pass the total allocation size to dealloc automatically

Richard Feldman (Feb 05 2025 at 15:11):

I think whether or not it was possible depended on some seamless slice implementation details?

Richard Feldman (Feb 05 2025 at 15:12):

and I thought we ended up in a place where we actually did always have the info on the Roc side and could pass it to dealloc, but maybe I'm misremembering :sweat_smile:

Brendan Hansknecht (Feb 05 2025 at 16:34):

Yeah, I always end up thinking we can. Then I realize that we store the number of live elements on the heap for refcounted seamless slices. That is not the size. The size is the full capacity, which a seamless slice has no way to get.

Richard Feldman (Feb 05 2025 at 19:02):

ahhh right

Richard Feldman (Feb 05 2025 at 19:02):

yeah I remember thinking this changed when we changed the representation of how that's stored in memory

Richard Feldman (Feb 05 2025 at 19:03):

but I think we actually ended up with a representation where we don't know it

Luke Boswell (May 19 2025 at 23:19):

Luke Boswell said:

Brendan Hansknecht and I have been cooking... we've put together a working prototype of roc build with an example platform, and a fake roc app.o object file.

All the files are sitting on this branch. We will probably migrate into the roc repo -- now that it's less of a hack. I've included some explanation and notes in the README in case that helps.

https://github.com/lukewilliamboswell/roc-platform-template-zig/tree/calling-roc

If you want to try it out...
$ zig build-obj host/app.zig
$ zig build-lib host/main.zig
$ zig build-exe app.o libmain.a
$ ./app
info: Running Roc APP
Hello
There are a few things different from the current way we do things, and we've tried to implement the ideal based on our previous design discussions.

Now would be a good time to discuss the API, and if there are ways we can improve things.

I'm looking at Richard's PR https://github.com/roc-lang/roc/pull/7795 and thinking about this work we did. I wonder if our design has evolved much from this and if it's worth updating this again so we have a test platform ready to go.

Brendan Hansknecht (May 19 2025 at 23:33):

I think it is mostly the same, but yeah, some minor differences

Luke Boswell (Jun 24 2025 at 05:16):

@Brendan Hansknecht -- I started writing this as a comment in that other thread... :smiley:

We're fast approaching the point where I'd like to pick your brains on how to actually implement this interpreter shim thing. We're really close to having single module/expression evaluation working in a simple form.

What comes next is fuzzy for me, particularly with the platform integration.

I'm of the opinion that the platform supplies a host executable that has embedded a roc compiler/interpreter (libroc) which can be used to load, compile, and execute .roc code and call relevant platform provided IO/effects.

Running an app using the roc cli, i.e roc my_demo_app.roc, roc is then calling this platform supplied executable and passing through the arguments (my_demo_app.roc etc) for the interpreter to run.

Luke Boswell (Jun 24 2025 at 05:22):

Alternatively, I think is the intended design is that the roc cli compiles the app into a canonical IR (including comp-time eval etc) then produces a static library (with the builtin bitcode included) that represents the app.o part.

From a platform's perspective they could be calling a fully compiled app (and optimised using LLVM) app.o, however internally it is using an interpreter at runtime to evaluate the code when the host calls into roc.

Brendan Hansknecht (Jun 24 2025 at 05:27):

Yeah, it will be interesting making the shim and getting this all working together

Brendan Hansknecht (Jun 24 2025 at 05:28):

I have ideas, but will be interesting to see if it works how I expect when we implement it in practice

Luke Boswell (Jul 16 2025 at 22:54):

Brendan Hansknecht said:

Nice base doc. One note, we don't want to hardcode the entry point. There can be many, but that is just a minor note.

FYSA we are cooking a plan to have a single entrypoint to start with, to simplify the integration and get things working.

If we can get the llvm-objcopy library working like we have for lld then Richard has an idea for supporting up to N (say 256) entrypoints by renaming the symbols in our interpreter shim before the cli links with the platform host for combined interpreter executable.

Luke Boswell (Jul 16 2025 at 22:56):

That way the platform author doesn't need to change anything. they provide a static library e.g. host.a and then the roc cli can link that with either the interpreter shim (i.e. roc run for fast dev loop), or with the LLVM optimised machine code and there is no difference.

Luke Boswell (Jul 16 2025 at 22:58):

I had a couple of questions that came up yesterday that I wanted to get down while I'm thinking of it.

Luke Boswell (Jul 16 2025 at 22:58):

Do we want to change roc_dealloc to include the size of the allocation. I realised without this we need to track the size of allocations manually in the host in order to play nicely with Zig's allocators.

I remember @Oskar Hahn had something similar when we was building a Go platform.

Luke Boswell (Jul 16 2025 at 23:00):

If roc_alloc is being passed into Roc... does this change the zig builtins?

We currently assume that roc_alloc is linked and available globally, but it's just a function pointer now.

I need to explore this further... so this question may not make much sense.

Luke Boswell (Jul 16 2025 at 23:02):

Should we link libC with our interpreter shim? I wasn't sure if we needed it or if it made any difference.

Notification Bot (Jul 16 2025 at 23:03):

6 messages were moved here from #compiler development > casual conversation by Luke Boswell.

Richard Feldman (Jul 16 2025 at 23:22):

Luke Boswell said:

Brendan Hansknecht said:

Nice base doc. One note, we don't want to hardcode the entry point. There can be many, but that is just a minor note.

FYSA we are cooking a plan to have a single entrypoint to start with, to simplify the integration and get things working.

If we can get the llvm-objcopy library working like we have for lld then Richard has an idea for supporting up to N (say 256) entrypoints by renaming the symbols in our interpreter shim before the cli links with the platform host for combined interpreter executable.

I found a better way btw; can add symbols and it'll be fine

Richard Feldman (Jul 16 2025 at 23:23):

Luke Boswell said:

If roc_alloc is being passed into Roc... does this change the zig builtins?

We currently assume that roc_alloc is linked and available globally, but it's just a function pointer now.

you're correct! We'll have to change all of them to accept function pointers to roc_alloc etc

Brendan Hansknecht (Jul 17 2025 at 01:02):

Luke Boswell said:

That way the platform author doesn't need to change anything. they provide a static library e.g. host.a and then the roc cli can link that with either the interpreter shim (i.e. roc run for fast dev loop), or with the LLVM optimised machine code and there is no difference.

I don't understand this. Even with 500 entry points, the platform author shouldn't need to change anything

Brendan Hansknecht (Jul 17 2025 at 01:06):

Luke Boswell said:

Do we want to change roc_dealloc to include the size of the allocation. I realised without this we need to track the size of allocations manually in the host in order to play nicely with Zig's allocators.

I remember Oskar Hahn had something similar when we was building a Go platform.

I forget what we decided here. Either we need to modify lists to store size of the allocation on the heap...or we need the platform to do it.

Luke Boswell (Jul 17 2025 at 01:19):

That's helpful context. I might try and dig out our conversation about it.

I'm thinking we should aim to make this as friendly as possible for platform dev as long as it's not a massive performance cost. It sounds like the information needs to be saved anyway, if roc does it internally we can be sure it's done correctly I guess.

Richard Feldman (Jul 17 2025 at 01:27):

Brendan Hansknecht said:

Luke Boswell said:

Do we want to change roc_dealloc to include the size of the allocation. I realised without this we need to track the size of allocations manually in the host in order to play nicely with Zig's allocators.

I remember Oskar Hahn had something similar when we was building a Go platform.

I forget what we decided here. Either we need to modify lists to store size of the allocation on the heap...or we need the platform to do it.

yeah I think the host should do it

Richard Feldman (Jul 17 2025 at 01:28):

the thing is, a lot of allocators store size on every allocation anyway, and so it's wasteful for us to automatically store it again

Richard Feldman (Jul 17 2025 at 01:29):

but for allocators that don't do that, they can just have their roc_alloc implementation store an extra usize for the size and write it in there before they return the pointer (to right after the usize they stored)

Richard Feldman (Jul 17 2025 at 01:29):

and then during deallocation they can just look right in front of the allocation to find the usize that they stored earlier in roc_alloc

Richard Feldman (Jul 17 2025 at 01:29):

we can and should pass the alignment though

Richard Feldman (Jul 17 2025 at 01:30):

because that's statically known, and it helps any roc_alloc author who's doing that trick avoid having to conservatively allocate space for the count

Brendan Hansknecht (Jul 17 2025 at 02:00):

Richard Feldman said:

the thing is, a lot of allocators store size on every allocation anyway, and so it's wasteful for us to automatically store it again

To be fair, I think it is often know for small allocations, but not always tracked for large allocations... But in general, yeah, allocators tend to track it cause they are based on the malloc api

Luke Boswell (Jul 17 2025 at 04:54):

Ok, sounds good :+1:

Last updated: Jul 26 2025 at 12:14 UTC