examples: Refactoring bindings examples

[kassane]

Summary

Refactoring Zig and D examples

Impact

This refactoring involves giving a better understanding of the usefulness of certain examples.
If these tools don't have any real appeal, then they're completely useless.

Step changes

• improvement hello_zig
• use Zig std.mem.Allocator + std containers in example (Zig std works in RTOS??)
• improvement hello_d using importC (get nuttx include) on betterC mode no GC (garbage collector)
• make another example, beyond hello_world.

Testing

• Zig make easy C ffi

How?

nuttx-apps/examples/hello_zig/hello_zig.zig

Lines 29 to 35 in 19e8f6a

	// nuttx namespace
	const nuttx = struct {
	pub const c = @cImport({
	@cInclude("nuttx/config.h");
	@cInclude("stdio.h");
	});
	};

nuttx-apps/examples/hello_zig/hello_zig.zig

Lines 39 to 40 in 19e8f6a

	// typedef alias
	const printf = nuttx.c.printf;

nuttx-apps/examples/hello_zig/hello_zig.zig

Lines 52 to 59 in 19e8f6a

	fn hello_zig(_: c_int, _: ?[*]const [*]const u8) callconv(.C) c_int {
	print("[{s}]: Hello, Zig!\n", .{nuttx.c.CONFIG_ARCH_BOARD});
	return 0;
	}
	fn print(comptime fmt: [*:0]const u8, args: anytype) void {
	_ = printf(std.fmt.comptimePrint(std.mem.span(fmt), args));
	}

$ qemu-system-riscv32 \
    -semihosting \
    -M virt,aclint=on \
    -cpu rv32 -smp 8 \
    -bios none \
    -kernel nuttx -nographic
NuttShell (NSH) NuttX-12.6.0-RC1
nsh> hello_zig
[rv-virt]: Hello, Zig!

---

Dlang

$ qemu-system-riscv32 \
    -semihosting \
    -M virt,aclint=on \
    -cpu rv32 -smp 8 \
    -bios none \
    -kernel nuttx -nographic
NuttShell (NSH) NuttX-12.6.0-RC1
nsh> hello_d
Hello World, [generic-rv32]!
hello_d_main: Saying hello from the dynamically constructed instance
HelloWorld: mSecret=0
DHelloWorld.HelloWorld: CONSTRUCTION FAILED!
Constructor
hello_d_main: Saying hello from the instance constructed on the stack
HelloWorld: mSecret=42
DHelloWorld.HelloWorld: Hello, World!!
Destructor

Reference

• tools/ci: Add more bindings apps for QEMU RISC-V. nuttx#13139
• [HELP] FFI compatiblity issues nuttx#12960

cc: @lupyuen

[kassane]

About Zig's progress.

Of all these languages that have internal or external facilities for interoperability with C (some C++ too) zig proves to be very practical, providing built-in auto-conversion (C2Zig).

However, in the future Zig will make LLVM optional and some of the features will no longer be provided by default (maybe as an add-on).
In this case @cImport will no longer be provided and will follow the same Rust style (like, bindgen-rs) as the third-party translate-c application.

Note: unlike bindgen-rs and importC (I don't know how to evaluate Swift yet), @cImport and translate-c not only "translate" the declarations in the header but also the implementation (header-only) if available. Similar to c2rust!!

FFI method

• Rust: need bindgen or c2rust
• D: importC
• Swift: Bridging header or clang modulemap.
• Zig: @cImport/@cInclude or translate-c

References

• move @cImport to the build system ziglang/zig#20630
• zig cc, zig c++, zig translate-c and other subcommands without a clang/llvm dependency in the compiler binary ziglang/zig#20875

[xiaoxiang781216]

@kassane please fix ci warning:

Error: /home/runner/work/nuttx-apps/nuttx-apps/apps/examples/hello_d/nuttx_std.c:2:1: error: Relative file path does not match actual file
Error: /home/runner/work/nuttx-apps/nuttx-apps/apps/examples/hello_d/nuttx_std.c:32:1: error: "Private/Public Functions" not found! File will not be checked
Error: Process completed with exit code 1.

[lupyuen]

@kassane sorry I missed this, wonder if it might be better to blink the LED like leds_rust, instead of doing GPIO?

That's because we can test it on QEMU RISC-V, which has an LED Driver. We don't have a GPIO Driver for QEMU. Thanks!

[kassane]

@kassane sorry I missed this, wonder if it might be better to blink the LED like leds_rust, instead of doing GPIO?

For me it's no problem. I can change the solution to leds_zig.

I will do it then!

[kassane]

New zig example added - using global_allocator.

[kassane]

@lupyuen,

Note

Curious note regarding leds_swift.

Having completed the zig example. I have taken the time and concepts to try to implement the swift port (newly embedded).
However, embedded ABI support is incomplete, for example Variadic functions are not yet available on the embedded module.
C Macro support also limited, need rewrite port

Swift-Embedded support status:
https://github.com/swiftlang/swift/blob/main/docs/EmbeddedSwift/EmbeddedSwiftStatus.md#embedded-standard-library-breakdown

leds-sample: https://gist.github.com/kassane/03a792f92b2430b350429dfa51dd5532

let _ULEDBASE: UInt = 0 // You need to set this to the correct value
let _IOC_TYPE_MASK: UInt = 0xff << 8 // Adjust this based on your system's IOC structure

func _IOC(_ type: UInt, _ nr: UInt) -> UInt {
    return (type << 8) | nr
}

func _IOC_TYPE(_ nr: UInt) -> UInt {
    return (nr & _IOC_TYPE_MASK) >> 8
}

func _ULEDIOCVALID(_ c: UInt) -> Bool {
    return _IOC_TYPE(c) == _ULEDBASE
}

func _ULEDIOC<T: BinaryInteger>(_ nr: T) -> T {
    return T(_IOC(_ULEDBASE, UInt(nr)))
}

let ULEDIOC_SUPPORTED: Int32 = _ULEDIOC(0x0001)
let ULEDIOC_SETALL : Int32 =   _ULEDIOC(0x0003)

# fd = open(CONFIG_EXAMPLES_LEDS_DEVPATH, O_WRONLY)
error: 'open' is unavailable: Variadic function is unavailable
# var ret = ioctl(fd, ULEDIOC_SUPPORTED, supported)
note: 'ioctl' has been explicitly marked unavailable

[lupyuen]

Looks great thanks!