@foone could not agree more. also when doing API/ABI it is good to use explicit size types so that the binary interface stays constant for 32-bit and 64-bit builds. Makes debugging experience so much more lean.

@cfbolz I do that sort of thing over here occasionally and informally. E.g. I had this bug that I was hunting for over a month (yep, was total nightmare at times but I learned RISC-V assembly in the process so I guess it was for profit): https://github.com/keystone-enclave/keystone/issues/378

Then I wrote this post to have something generically applicable to try out in future when I have paging issues in RISC-V: https://social.kernel.org/notice/AbcKucebyfykZkSo4W. I don't want to keep this too formal. I try to remember adding #note to everything that I might want to checkup at times to get some ideas. Sort of scrap book in Mastodon 🙂

It is pretty easy to recall at least the year when I was working "something", and thus I feel that a single hashtag can help a lot already and is low-barrier at the same time.

@liw Physical accident along the lines of Ariane flight V88 is entirely possible in Rust, as it was in ADA. The exception is different (integer overflow) but similar in the sense that you have a default exception behaviour, which can trip your system in unfortunate circumstances.

@liw I’ve tried this for out of memory conditions (aka memory exhaustion) in Rust but there’s no -ENOMEM :-) In unstable there is handle_alloc_error() but it is. sort of complicated track to adapt. Would be nice if you could do this every and each at the site, as callback indirection sucks…

In this thread I see one common and wrong conclusion:

“Yeah, but there are also other application areas, such as embedded environments with less RAM and no memory overcomittment.”

For restricted embedded payloads and stuff like that you usually define metrics already at the compile time, and use crates such as heapless. It is exactly dynamic over-committed memory where it would be nice to explicitly deal with this unexpected corner case.

It is pretty hard to sometimes discuss about memory issues in Rust with “rustaceans” because they are living in the myth of Rust being memory-safe. Nothing is never fully memory-safe.

@liw I’ve tried this for out of memory conditions (aka memory exhaustion) in Rust but there’s no -ENOMEM :-) In unstable there is handle_alloc_error() but it is. sort of complicated track to adapt. Would be nice if you could do this every and each at the site, as callback indirection sucks…

In this thread I see one common and wrong conclusion:

“Yeah, but there are also other application areas, such as embedded environments with less RAM and no memory overcomittment.”

For restricted embedded payloads and stuff like that you usually define metrics already at the compile time, and use crates such as heapless. It is exactly dynamic over-committed memory where it would be nice to explicitly deal with this unexpected corner case.

It is pretty hard to sometimes discuss about memory issues in Rust with “rustaceans” because they are living in the myth of Rust being memory-safe. Nothing is never fully memory-safe.

Kaljantaikevennys!

and one from five years ago https://soundcloud.com/triplaespresso/myrsky

watched this embarrassingly many times https://www.youtube.com/watch?v=M8bt2SJnuX4

making new tracks over the weekend, here's one released last june https://nullzone2007.bandcamp.com/track/lumo-ava-2

@Elias vika marawalk

@jmorris given that this is possible i would give it a shot in the similar situation. there’s lot of nostd stuff that you can probably easily adapt to this framework like my go-to rust library heapless.

i’ve taken practice even in non-embedded (user space) rust that i prefer nostd and heapless structures to the max over features when picking dependencies for a rust program. sort of addition of minimizing the number of unsafe regions is to minimize the number of heapful regions.

@jawnsy @jonmasters i'm in the process of selling my soul to riscv

I don't know how I ever came up with this but looks pretty useful to remember :-)

macro(import_binary_as_elf Path Symbol Target)
    set(objcopy_flags -I binary -O default -B riscv)
    string(MAKE_C_IDENTIFIER ${Path} unstripped)
    add_custom_command(
        OUTPUT ${Path}.elf
        DEPENDS ${Target}
        COMMAND 
             ${CMAKE_OBJCOPY} ${objcopy_flags}
             ${Path} ${Path}.elf
        COMMAND
              ${CMAKE_OBJCOPY} -N
              _binary_${unstripped}_end ${Path}.elf
        COMMAND
              ${CMAKE_OBJCOPY} --redefine-sym
              _binary_${unstripped}_start=${Symbol}_start
              ${Path}.elf
        COMMAND
              ${CMAKE_OBJCOPY} --redefine-sym
              _binary_${unstripped}_size=${Symbol}_size
              ${Path}.elf
    )
    add_custom_target(${Symbol}_elf DEPENDS ${Path}.elf)
endmacro()

#cmake #riscv #embed #binary #elf #note

@jmorris My inital guess was no but then I googled a bit and found https://dev.to/kgrech/five-simple-steps-to-use-any-arduino-c-library-in-a-rust-project-1k78

@hasheddan The only thing I've read with thought is your "RISC-V Bytes" series. Salute and huge appreciation for writing those! Sound stuff.

I’d consider rewriting it with Rust and adr-hal.

quick #m8tracker #synthwave jam during kid's naptime

@swelljoe @mjg59 i prefer taco bell over puppets http://widgetsandshit.com/teddziuba/2010/10/taco-bell-programming.html