Process for adding other programming languages

[ethindp]

What are the steps for adding other languages to the Iced crate? I'd like to add the Ada language if that would be alright.

[wtfsck]

• Add a new crate with a public "C" API (only add funcs you need). In theory this can be re-used by other langs that can call C APIs
  • not everything needs to be supported at the moment, so add whatever you need (eg. decoder and some formatter?)
  • the other language (eg. Ada) will probably need to access the struct fields of Instruction by using field offsets since calling some C API to just return the field will be slower (can't inline)
• Add the Ada code calling into that new crate
• Update the generator to generate Ada enums and other constants

You can have a look at the Python and/or JavaScript crates I created too since they all use the Rust crate (although not by using a C API).

The generator is written in C#: https://github.com/icedland/iced/tree/master/src/csharp/Intel/Generator (you need .NET SDK 6.0)

dotnet run -c Release --project ~/path/to/iced/src/csharp/Intel/Generator/Generator.csproj

[ethindp]

So for step 1, would I copy the iced-x86 crate and then add extern "C"/#[no_mangle] on the functions I need to make external? And what files would I delete?

[ethindp]

cc @wtfsck

[wtfsck]

That C API crate should reference iced-x86 (no need to copy the whole thing) and just add a C APIs for some funcs you need for your Ada code. Eg. a fn to create a decoder and other fns the Ada code needs (eg. decode()).

[ethindp]

@wtfsck Oh, okay, so I'd create a C API for Iced-x86, and create functions for encoding/decoding/block decoding/encoding or whatever I need. And then on the Ada side of things I'd modify the generator to generate the instruction-based subprograms to emit instructions, or enumerations for decoders? Not really sure how decoding would work without that on the C side though...

[wtfsck]

There's no C side, it's all Rust with a C API.

The C API crate (written in Rust) will be small and just convert the ptrs passed to it to rust references and call the original fns in the iced-x86 crate. Eg. a 'create decoder' fn would call Decoder::new(), box it, and return the ptr to the caller (eg. Ada code).

#[no_mangle]//etc
fn decoder_new() -> some-ptr {
let d = Decoder::new(xxx);
// box it
// return ptr
}

// other fns here, eg. decode()

-- the Ada code loads the dll or links to it and then calls the above methods (C API)

The generator should be updated to generate all enums the Ada code needs (the other enums can be ignored).

[ethindp]

I was thinking of wanting to use Iced in an ada kernel project/on embedded systems. That's why I asked about being able to possibly generate the crate as an Ada project perhaps.

[wtfsck]

If you mean generate 100% Ada code, the generator can't do that. You'd have to convert the non-generated code to Ada. It should be easier to just call into a C API, I think Ada supports that.

[ethindp]

Yeah, I'll look into it. Not really sure how using it in an embedded context would work in that case though.