<re_irc>
< (@adamgreig:matrix.org)> yea, "orr.w" is a T2 encoding only
<re_irc>
< (@jamesmunns:beeper.com)> makes sense
<re_irc>
< (@adamgreig:matrix.org)> though it's only needed here for the optional shift parameter, "ORRS" in T1 is "ORRS Rdn Rm" while T2 has "ORR.W Rd Rn Rm <shift>"
<re_irc>
< (@jamesmunns:beeper.com)> yeah, that seems integral to the "problematic opt"
<re_irc>
< (@adamgreig:matrix.org)> yea
<re_irc>
< (@adamgreig:matrix.org)> ".W" is for wiiiiide instructions
<re_irc>
< (@jamesmunns:beeper.com)> or at least - one "known problematic opt". can't rule out others existing.
<re_irc>
< (@jamesmunns:beeper.com)> yeah, I guess the ".n" for narrow instructions is implicit?
<re_irc>
< (@adamgreig:matrix.org)> I think you can put it to enforce narrow or error if not possible
<re_irc>
< (@adamgreig:matrix.org)> ah, if 16 and 32 bit are both available it must pick the 16, so...
fabic_ has joined #rust-embedded
<re_irc>
< (@peter9477:matrix.org)> : We didn't try without LTO, but recall (if you ever heard) that our stuff worked fine on nightly until 2023-02-05, so I think this is definitely a case where moving things around, or minor unrelated changes in the compiler, are likely to make the latent issue come and go. After all, the code probably would have worked fine even with the misaligned stack if the compiler/linker just happened to make...
<re_irc>
... that 2-element u32 array be positioned 4 bytes off from where it was.
<re_irc>
< (@adamgreig:matrix.org)> yea, all my repros were with LTO enabled
<re_irc>
< (@adamgreig:matrix.org)> I wonder if the compiler deliberately makes it 8-byte aligned to allow this trick, though...
<re_irc>
< (@9names:matrix.org)> I had some repros with LTO, some without, depending on compiler version etc. Getting optimisations to consistently apply to code is hard.
brazuca has quit [Quit: Client closed]
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 248 seconds]
lehmrob has joined #rust-embedded
lehmrob has quit [Ping timeout: 248 seconds]
emerent has quit [Remote host closed the connection]
emerent has joined #rust-embedded
dc740 has joined #rust-embedded
<re_irc>
< (@korken89:matrix.org)> Has anyone seen something similar to a pub/sub communication bus that's designed for use within an async (PC) application? I'm looking for stuff in that domain, and I expect that there should be no need for serde so more like something that just sends "Arc<T>" to all "subscribers"
<re_irc>
< (@korken89:matrix.org)> I think one can orchestrate this with "tokio::sync::mpsc" and a macro the generates the bus, but it feels like I'm not the first one to want this
<re_irc>
< (@korken89:matrix.org)> * One
fabic_ has quit [Ping timeout: 255 seconds]
fabic_ has joined #rust-embedded
<re_irc>
< (@barafael:matrix.org)> So, like a `tokio::sync::mpsc`?
<re_irc>
< (@korken89:matrix.org)> : Like that but with known topics
<re_irc>
< (@korken89:matrix.org)> : Thanks, I'll give it a look!
<re_irc>
< (@korken89:matrix.org)> I think a thin wrapper on "broadcast" will get me like 95% there
<re_irc>
< (@barafael:matrix.org)> Are the topics only known at runtime? That's interesting, I usually get away with enums...
<re_irc>
< (@barafael:matrix.org)> -That's interesting, I usually get away with enums...
<re_irc>
< (@korken89:matrix.org)> Compile time
<re_irc>
< (@korken89:matrix.org)> "topic" means any identifier here
<re_irc>
< (@korken89:matrix.org)> It could be an enum
dc740 has quit [Remote host closed the connection]
<re_irc>
< (@barafael:matrix.org)> It's somewhat clumsy to send data to everybody and let them decide if they case about it, but actually maybe not that bad
<re_irc>
< (@barafael:matrix.org)> * care
<re_irc>
< (@korken89:matrix.org)> That's the thing, I only want to send to "subscribed" tasks
<re_irc>
< (@korken89:matrix.org)> So I think broadcast should do it well
<re_irc>
< (@korken89:matrix.org)> As only the ones wanting it will ".subscribe()"
<re_irc>
< (@barafael:matrix.org)> Ah, so one broadcast channel per topic?
<re_irc>
< (@korken89:matrix.org)> Yeah I was thinking like that
<re_irc>
< (@korken89:matrix.org)> Hmm, I'll give it a try
<re_irc>
< (@korken89:matrix.org)> It will be loads better than serializing everything to JSON, shipping in on MQTT, have the same att read the MQTT, deserialize and act :P
<re_irc>
< (@korken89:matrix.org)> * app
<re_irc>
< (@korken89:matrix.org)> I think the overhead of an "Arc<T>" might be lower ;)
<re_irc>
< (@lulf_:matrix.org)> If you don't need persistence, no need to use an mqtt broker for sure.
fabic_ has quit [Ping timeout: 255 seconds]
lehmrob has joined #rust-embedded
<re_irc>
< (@barafael:matrix.org)> Just do mqtt with raw pointers then :)
<re_irc>
< (@jamesmunns:beeper.com)> I was gonna say "arc mutex hashmap <String, BroadcastChannel>" for "subscribing" :p
<re_irc>
< (@jamesmunns:beeper.com)> So a mutex when you're adding/looking up a "topic"
<re_irc>
< (@jamesmunns:beeper.com)> Ah, unless messages have different types
<re_irc>
< (@huntc:matrix.org)> : It’s a commit log. We also use channel and broadcast. The IoT example may help.
<re_irc>
Thanks for mentioning !
<re_irc>
< (@jamesmunns:beeper.com)> They might be trickier :p
<re_irc>
< (@korken89:matrix.org)> : Hmm, I'm not sure if I'm looking in the right place
<re_irc>
< (@korken89:matrix.org)> I have just not made the macro
<re_irc>
< (@korken89:matrix.org)> Though it is a trivial macro that even can me a macro_rules! one
<re_irc>
< (@korken89:matrix.org)> Skip the enum
<re_irc>
< (@korken89:matrix.org)> Though it is a trivial macro that even can be a macro_rules! one
<re_irc>
< (@jamesmunns:beeper.com)> by the way, I have a _really_ cursed way of type erasing a bunch of channels into a single data structure like a hash map, where you have to ask for the "right" type you expect on the channel
<re_irc>
< (@jamesmunns:beeper.com)> I can find that for you if you want to go down that route.
<re_irc>
< (@korken89:matrix.org)> Sure, love to have a look
<re_irc>
< (@jamesmunns:beeper.com)> lemme see if I can find it. I have poc somewhere, then I integrated it into mnemos' driver discovery service
<re_irc>
- heap allocations are always pointer sized
<re_irc>
< (@jamesmunns:beeper.com)> basically uses the fact that:
<re_irc>
- you can use the type id
<re_irc>
< (@jamesmunns:beeper.com)> so you do something like:
<re_irc>
map.get_channel::<ExpectedValue>("key")
<re_irc>
< (@jamesmunns:beeper.com)> which only gives you back the channel for "key" if "ExpectedValue" was the type that was used when registering the channel
<re_irc>
< (@jamesmunns:beeper.com)> there's a bit more in that poc, because I send serialized data (for format/abi stability reasons), but you don't have to do that, you could just use the type erasure bits.
<re_irc>
< (@jamesmunns:beeper.com)> (this is very C "void*" brained, tho with at least a _little_ type safety via using "TypeId" to validate the expected type of the received object)
<re_irc>
< (@jamesmunns:beeper.com)> (tho I'm a _little_ proud of the _map_deser_ function, which monomorphizes to a bare function you can use as a deserializer for any type - you probably don't need that like I do for mnemos)
<re_irc>
< (@jamesmunns:beeper.com)> Sure, can do later tonight
<cr1901>
Thanks, I'll update cargo .config.toml for the time being. The commits I have now just won't compile on any other machines for now- what a shame/loss :P
<cr1901>
(joke)
fabic_ has quit [Ping timeout: 246 seconds]
<cr1901>
Ugh, semver depends on alloc even in no_std envs
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
<re_irc>
<knickish> Just got basic compile-time linear algebra working, and thought people here might be interested. I can't find anything similar that exists already, but not 100% sure. https://github.com/knickish/constgebra
loki_val has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
<cr1901>
Yea I am not paid enough for this lmao... embedded_semver exists, but depends on bitvec, which depends on radium 0.7, which is broke on msp430/16-bit targets lmao
<re_irc>
< (@jamesmunns:beeper.com)> Reminder, if you've ever wanted postcard to have a schema, or a story around forwards/backwards compat, or other related topics, I'd love to hear from you in https://github.com/jamesmunns/postcard/issues/92 !
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
rardiol has joined #rust-embedded
<re_irc>
< (@jamesmunns:beeper.com)> (and now 1.0.4 because there was a bugfix PR I forgot to merge first 😅)
fabic_ has joined #rust-embedded
<cr1901>
jamesmunns: Appreciated. Now only two more outstanding issues now I realized semver _also_ depends on alloc