Steve Williams (May 14 2025 at 09:14): Steve Williams (May 14 2025 at 09:14):Clues welcome how to resolve. Thanks in advance.
https://github.com/AssemblyScript/assemblyscript/issues/2658
Chris Fallin (May 15 2025 at 04:32):@Steve Williams AssemblyScript is not a Bytecode Alliance project, so you're fairly unlikely to receive useful hints here -- if I were you I would seek out help in their community. Best of luck!
Steve Williams (May 15 2025 at 08:57):Hi Chris - understood, but you guys understand wasm binding in low level detail that I don't yet. What I'm trying to understand is if the wasm eco-system makes such binding possible & it's just the case that their compiler and/or language lacks the necessary or if there's something fundamental missing preventing this connection from being made.
Ralph (May 15 2025 at 14:28):these: it's just the case that their compiler and/or language lacks the necessary or if there's something fundamental missing preventing this connection from being made would be AssemblyScript questions. That issue is older and clearly had a solution but it wasn't pursued.
Ralph (May 15 2025 at 14:29):I mean, it's all just software, as they say. Mostly anything can be done. But as you're asking about AssemblyScript, following up on that issue you post is likely the best path.
Steve Williams (May 16 2025 at 09:48):just linking libraries together with appropriate calling conventions & there's nothing fundamental in wasm stopping that from happening. that's all I needed to hear, thanks.
Steve Williams (Jun 21 2025 at 12:35):hey. sorry to come back to this.
the following : https://github.com/AssemblyScript/assemblyscript/issues/741
says blocking issue is "we need reference types and multi memories for linking more complex code in one wasm sandbox."
is this an assembly script issue - stuff they have to do or a wasm architecture issue, please.
trying to understand what needed to connect assemblyscript & c++ in the same wasm app
Ralph (Jun 21 2025 at 15:34):maybe they have reference types now? that last comment was 2022
Steve Williams (Jun 21 2025 at 19:55):I don't even know what they are :) my tiny mind on this thus far sees there's some ascript code & some c/c++ code & a common calling convention somehow & each has its own memory for allocations & they're in the same address space for interop. are we solid with that ? its just a case of bash it until it'll link ? if so, I'll try & find the time to make it happen. cheers.
Chris Fallin (Jun 22 2025 at 01:03):Hi @Steve Williams -- I'll repeat what I noted above, that this isn't the venue for discussion about AssemblyScript. You've linked an issue on their repository; why not comment there and ask for any help you need?
We're generally very open and happy to help about the technologies that we work on specifically here, but it's a bit of an antipattern to try to lean on this community just because there are folks who know some of the related technologies and might be able to guess. Thanks!
Steve Williams (Jun 22 2025 at 05:16):coz I'm trying to understand if wasmtime is capable of linking code with 2 memory pools - one for each language or if they'd share the same pool somehow or how that would work. not asking anyone else to do the work & yeah thinking out loud coz not quite sure how to approach this yet. sorry :)
Steve Williams (Jun 22 2025 at 10:15):got it, I think with a little help from GPT. will post working example or cries for help depending on how it turns out :)
Steve Williams (Jun 22 2025 at 13:53):got it, I think. you can do stuff like this in assemblyscript:
// Import a function from another Wasm module (e.g., C) that doubles a value
@external("env", "doubleValue")
export declare function doubleValue(val: i32): i32;
sorry for bothering you guys. don't have a verified working example yet coz lots on but it seems straightforward from here.
Steve Williams (Jun 22 2025 at 14:33):there's this stuff - all new to me. here in case it interests anyone else.
https://component-model.bytecodealliance.org/language-support.html
Christof Petig (Jun 22 2025 at 16:00):I think this link is the wrong one as it points to the documentation.
Steve Williams (Jun 22 2025 at 17:37):All I actually need is ability to import & export functions, which is an assemblyscript issue.
it's as simple as this (pure assemblyscript) apparently.
export function MyExportedFunction(val: i32): i32 {
return val * 2;
}
// Import a function from another Wasm module (e.g., C) that doubles a value
@external("env", "MyImportedFunction")
export declare function MyImportedFunction(val: i32): i32;
aware its been stated assemblyscript is not a bytecode alliance project & I should do this stuff elsewhere, apologies for the offroad.
Steve Williams (Jun 22 2025 at 17:42):& as I'm importing from host code, doesn't matter status of linking modules from different languages right now though resolving that at some point would be nice.
Steve Williams (Jun 22 2025 at 18:13):the issue going further from my very limited understanding so far, is assemblyscript can ony generate .wasm not .o files so there's no opportunity to link other stuff. doesnt sound the hardest job ever to roll that back a step & then we should be good to go with a link step pulling in whatever.
Ralph (Jun 23 2025 at 13:02):we certainly wish you luck! Keep working at it. We just can't help much here. :-) and :-(
Last updated: Dec 06 2025 at 06:05 UTC