<re_irc>
<9names (@9names:matrix.org)> Yeah I didn't understand the argument either, but it didn't seem worth derailing a productive thread to ask what they meant.
<cr1901>
agg: Are users of cortex-m expected to write explicit compiler barriers if they don't want code before/after a nop to be reordered?
<re_irc>
<thalesfragoso> cr1901: If cfg_full isn't enabled, that load will use real atomics that will then mix with emulated ones used in CAS
causal has joined #rust-embedded
<cr1901>
stupid follow up- what's wrong with that? One thread using "real atomics" and another thread using the emulated ones is a data race?
<re_irc>
<thalesfragoso> cr1901: Not in this specific case, i.e. using critical section on single core
<re_irc>
<thalesfragoso> But in other situations, like if using a lock, that would make the CAS one non atomic, because the hardware one doesn't respect the lock
<cr1901>
But Rust atomics don't use locks
<cr1901>
(By lock, I assume you mean "loop until you can safely get to the resource")
<cr1901>
(which critical_sections by themselves don't do- they "never-fail" to take the lock)
<re_irc>
<thalesfragoso> Sorry, I quoted the wrong message
<re_irc>
<thalesfragoso> Like I said, I don't think there's a problem when using critical section in single core
<re_irc>
<thalesfragoso> But that isn't the only way to emulate atomics
<cr1901>
oooooh okay, I get it now
<cr1901>
that's fair
<re_irc>
<9names (@9names:matrix.org)> critical_section (the crate) can internally be in implemented with locks, that's what rp2040 does in order to enforce mutual exclusion across two cores. But by the old scheme, it only needed atomic polyfill for CAS, so it could combine native load/store with emulated CAS.
<re_irc>
It didn't click for me until thalesfragoso spelled it out
<cr1901>
>by the old scheme?
<re_irc>
<9names (@9names:matrix.org)> Where cm0 supports atomic load/store in llvm without supporting atomic insns
<cr1901>
ahhh alright... and that explains the "multi core" part of the message too
<cr1901>
Strictly speaking Idk if what I do for msp430_atomic is actually sound. It's based on a few things I know for sure about msp430 and at least one thing I believe is true but I haven't verified
<cr1901>
Btw, does cm0 use regular load/stores for atomic load/store?
<cr1901>
b/c the bus width is going to be 32-bits and can be done in one xaction?
<re_irc>
<9names (@9names:matrix.org)> that's my understanding of it, yes
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
brazuca has quit [Ping timeout: 252 seconds]
<re_irc>
<thalesfragoso> cr1901: For relaxed atomics, yes. There will be some DMBs instructions too for not relaxed
<re_irc>
<thalesfragoso> I mean, this is what is done in rust currently. And people want to maintain that, LLVM removed it, but we will have to find a way
<re_irc>
<thalesfragoso> There are patches to LLVM to add options to bring the old behavior back if you promise to not link to libatomic and friends
<re_irc>
<quarky> Yo, does anyone have a target json for armv5te freestanding, big endian? I found a few armv5te-none-eabi jsons but they're all little endian, and my best attempt has resulted in weird issues with mixed big and little endian object files
<re_irc>
<dirbaio> it could run in this order: thread B load, thread A store, thread B store
<re_irc>
<dirbaio> which would be wrong
<re_irc>
<dirbaio> this is because "critical-section"'s definition of a "critical section" is "no other critical section can run concurrently", not "no other code can run concurrently"
<re_irc>
<dirbaio> in single-core, with a "disable irqs" critical section, it really is "no other code can run concurrently"
<re_irc>
<dirbaio> but that's not guaranteed by "critical-section"
<re_irc>
<dirbaio> (and I don't think it should...)
<re_irc>
<dirbaio> it's sad that even load/store requires CS! :(
dc740 has joined #rust-embedded
Guest14 has joined #rust-embedded
Guest14 is now known as brazuca
thomas25 has joined #rust-embedded
<re_irc>
<SEGFAULT> Does anyone know where I can get a Rust compatible dev board that has an ardino shield header on it thats actually in stock to buy today.
<re_irc>
<henrik_alser> SEGFAULT: Any stm32 Nucleo or nrf52840-dk
<re_irc>
<SEGFAULT> yes but does anyone know where I can find one in stock, these things are unobtainium
<re_irc>
<henrik_alser> Same price so go with that one :)
<re_irc>
<SEGFAULT> looks great
<re_irc>
<henrik_alser> Yeah it’s a nice chip
<re_irc>
<SEGFAULT> thanks for the help, I am ordering now
<re_irc>
<henrik_alser> Have fun!
<re_irc>
<henrik_alser> Shout if you need guidance when you have it
<re_irc>
<SEGFAULT> Oh I will
<re_irc>
<SEGFAULT> I have set up STM32's with rust before,
<re_irc>
<SEGFAULT> what I will ultimately need to do is turn these things into LoRa modems
<re_irc>
<henrik_alser> So is that what you need the arduino header for?
<re_irc>
<henrik_alser> Some lora shield?
<re_irc>
<SEGFAULT> yup
<re_irc>
<henrik_alser> Fun, keep us posted :)
<re_irc>
<SEGFAULT> will do
<re_irc>
<skylardive1> I don't know if this is the right place to ask, but in a project with libc and no_std, how do we get _argv arguments from the type *const *const u8?
<re_irc>
<K900> How small do you need your binary to be then?
<re_irc>
<K900> A simple hello world executable should be below 100kb with those optimizations
<re_irc>
<skylardive1> im aware
<re_irc>
<skylardive1> i am challenging myself
<re_irc>
<skylardive1> how much does alloc add to the final size?
<re_irc>
<skylardive1> i thought you could alloc with core
<re_irc>
<K900> You can't
<re_irc>
<K900> If you're challenging yourself, you can probably write your own CString-ish wrapper
<re_irc>
<K900> But not being able to allocate memory will make things difficult
<re_irc>
<Campbell He> If you define an allocator, you can use "alloc" with "core"
<re_irc>
<K900> +if you want to actually _do something_ with it
<re_irc>
<K900> And honestly if you're dropping down to just "core" without "alloc", but with libc, you might as well be writing C
<re_irc>
<skylardive1> is there a resource for writing code like this?
<re_irc>
<K900> Like what?
<re_irc>
<skylardive1> no_std with libc
<re_irc>
<K900> I don't think so, because it's usually completely unnecessary
<re_irc>
<skylardive1> K900: i know, but that's literally the part i'm challenging myself with
<re_irc>
<K900> I mean if you're going to write C in Rust, you can just keep your args as "*mut u8"
<re_irc>
<K900> And do things with "strlen" or whatever
<re_irc>
<skylardive1> are you busy at the moment?
<re_irc>
<dirbaio> just write C and translate it with c2rust :P
<re_irc>
<skylardive1> if not, could you provide me with a example
<re_irc>
<K900> Example of what?
<re_irc>
<skylardive1> parsing argv
<re_irc>
<skylardive1> i still don't quite get it
<re_irc>
<dirbaio> for i in 0..argc {
<re_irc>
libc::puts(*argv.add(i))
<re_irc>
}
<re_irc>
<K900> You probably want "*argv.offset(i)" but yes
<re_irc>
<skylardive1> dirbaio: thanks!
<re_irc>
<skylardive1> *argv.offset(0)
<re_irc>
<skylardive1> yeah thats what im looking for
<re_irc>
<K900> Note that all of this is obviously wildly unsafe
<re_irc>
<K900> If you want something slightly less wildly unsafe, you can try "slice::from_raw_parts"
<re_irc>
<skylardive1> rust is a pretty big language
<re_irc>
<skylardive1> there's just so much i don't know
<re_irc>
<skylardive1> i have one more question, should i move to another place or can i ask here?
<re_irc>
<K900> Don't ask to ask
<re_irc>
<skylardive1> i agree, but i might have more questions in the future, so i think i might as well
<re_irc>
<skylardive1> anyways, say i have a slice of u32 integers. i want to convert them into a u8 slice instead like so: [0x12345678, 0x12345678] to [0x12, 0x,34, 0x56, 0x78, 0x12, 0x,34, 0x56, 0x78]
<re_irc>
<skylardive1> i looked it up but most of the options depend on std
<re_irc>
<K900> If you want to do it deterministically and want to stay within the confines of libc, you have to twiddle the bits yourself
<re_irc>
<K900> Also, you can't have a u8 slice without "alloc"
<re_irc>
<K900> Because you can't allocate backing storage for it
<re_irc>
<dirbaio> use slice::as_ptr, cast the ptr, then slice::from_raw_parts
<re_irc>
<skylardive1> so, let test = [0u8; 1000]; is using alloc?
<re_irc>
<K900> dirbaio: Only if the endianness matches
<re_irc>
<K900> skylardive1: No, that's fixed size
<re_irc>
<K900> And an array, not a slice
<re_irc>
<K900> Also there might be alignment related ABI restrictions
<re_irc>
<skylardive1> sorry i worded it wrong
<re_irc>
<skylardive1> it's a array
<re_irc>
<K900> The only way to do it _correctly_ would be to twiddle the bits
<re_irc>
<dirbaio> you'll get "[0x78, 0x56, 0x,34, 0x12, 0x78, 0x56, 0x,34, 0x12]" due to endianness though, look into "u32::to_be_bytes" to endian-swap them
<re_irc>
<K900> Oh yeah, actually, "to_be_bytes" should work because it returns a fixed size array
<re_irc>
<K900> That you can then merge into another fixed size array
<re_irc>
<skylardive1> oh? i can swap from endianness to say big endian on all archs with to_be_bytes?
<re_irc>
<K900> Yes
<re_irc>
<skylardive1> i think ill look into alloc
<re_irc>
<K900> It will likely be a no-op if the endianness matches, and it will do the bit-twiddling for you if it doesn't
<re_irc>
<K900> And it does not require "alloc"
<re_irc>
<skylardive1> but it seems core and alloc are seperate crates
<re_irc>
<K900> Because the return size is known at compile time
<re_irc>
<skylardive1> Hmmmmm
<re_irc>
<Campbell He> They are separate
<re_irc>
<skylardive1> in instances where i don't know the size i'll have to use alloc to use the heap
<re_irc>
<K900> You _could_ use "libc::malloc" directly
<re_irc>
<K900> And write your own types on top of that
<re_irc>
<Campbell He> Maybe can warp "libc::malloc" in "alloc"'s allocator and no need to define own types
<re_irc>
<K900> That is what std does normally, yes
<re_irc>
<Campbell He> Oh, I just know that. 🤣
<re_irc>
<skylardive1> Hmmmmmm
<re_irc>
<skylardive1> i didn't need to import core, but i have to with alloc, any specific reason why?
<re_irc>
<K900> Because "core" is always present
<re_irc>
<K900> And "alloc" may not be linked in at all
<re_irc>
<skylardive1> good point
<re_irc>
<Campbell He> Like when you doing a really small bare metal project, there may be no need to use "alloc"
<re_irc>
<K900> You can technically opt out of "core" as well, with "#[no_core]", but this is very likely explode
<re_irc>
<K900> The only reason it exists is to allow the compiler to implement "core"
<re_irc>
<K900> But if you're willing to shoot off the rest of your foot, you can try that
<re_irc>
<skylardive1> error: no global memory allocator found but one is required; link to std or add `#[global_allocator]` to a static item that implements the GlobalAlloc trait
<re_irc>
error: `#[alloc_error_handler]` function required, but not found
<re_irc>
<skylardive1> haha, i need core
<re_irc>
<K900> Yes, that is something you will now need to provide
<re_irc>
<K900> And no, it's not in "core"
<re_irc>
<Campbell He> You need to define an allocator
<re_irc>
<K900> It's in "std", "core" is platform independent
<re_irc>
<skylardive1> such as libc::malloc?
<re_irc>
<Campbell He> yes
brazuca has quit [Quit: Client closed]
<re_irc>
<Campbell He> you may find this page helpful
<re_irc>
<skylardive1> i'm trying to delcare this area "unsafe {}" but it's not letting me
<re_irc>
<Campbell He> you need "unsafe impl Sync for SimpleAllocator {}"
<re_irc>
<skylardive1> the trait bound "SimpleAllocator: GlobalAlloc" is not satisfied
<re_irc>
the trait "GlobalAlloc" is not implemented for "SimpleAllocator"
<re_irc>
<skylardive1> i don't get it, wasn't it to supposed to be able to use libc::malloc?
<re_irc>
<K900> It is not inherently supposed to do that
Guest14 has joined #rust-embedded
Guest14 is now known as brazuca
<re_irc>
<K900> You can implement your own allocator that uses it
<re_irc>
<skylardive1> i would need to define that in ALLOCATOR right
<re_irc>
<Campbell He> You just define a new struct. But there is no code to call "malloc" to really alloc
<re_irc>
<skylardive1> i scrolled a little further down the docs, there was a "unsafe" example already
<re_irc>
<skylardive1> i notice many "alloc" functions are in "core"
<re_irc>
<skylardive1> should i consistently use core, or should i use alloc as well? it seems to satisfy the code when i just use core
<re_irc>
<K900> "alloc" reexports some things from "core"
<re_irc>
<K900> And "std" reexports things from both
<re_irc>
<skylardive1> so, for the methods present in both libraries, i'll go with core
brazuca has quit [Quit: Client closed]
<re_irc>
<thalesfragoso> K900: Why would you need CString ? I mean, why would you need dynamic allocation ? You usually need CString when you are going the other path &str -> C null terminated string
Guest14 has joined #rust-embedded
Guest14 is now known as brazuca
<re_irc>
<K900> thalesfragoso: You need dynamic allocation to get a Rust "String" out of a "CStr"
<re_irc>
<thalesfragoso> K900: Well, but you don't always need a String itself, as in, you don't need it to parse args
cr1901_ is now known as cr1901
<re_irc>
<thalesfragoso> Why would you need CString ? I mean, why would you need dynamic allocation ? You usually need CString when you are going the other way &str -> C null terminated string
starblue has quit [Ping timeout: 268 seconds]
brazuca has quit [Quit: Client closed]
starblue has joined #rust-embedded
Guest14 has joined #rust-embedded
Guest14 is now known as brazuca
cr1901_ has joined #rust-embedded
cr1901 has quit [Killed (NickServ (GHOST command used by cr1901_))]