<re_irc>
< (@dirbaio:matrix.org)> : user does "register_interrupt!" on the interrupts they want the HAL to handle
<re_irc>
< (@dirbaio:matrix.org)> goal is to allow the HAL to handle interrupts (for writing async drivers
<re_irc>
< (@dirbaio:matrix.org)> +for example)
<re_irc>
< (@dirbaio:matrix.org)> without having the HAL handle all interrupts unconditionally, which would be bad for code size and would prevent you from manually handling some
dc740 has quit [Remote host closed the connection]
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
conplan has quit [Remote host closed the connection]
<re_irc>
< (@korken89:matrix.org)> : What said :) The issues of eager interrupt allocation can really throw a spanner in the works when stuff starts colliding.
<re_irc>
< (@korken89:matrix.org)> One thing we probably need to look at though is maybe supporting "#[cfg(...)]"s in some form
<re_irc>
< (@korken89:matrix.org)> I guarantee that people will want to enable/disable registrations based on features
<re_irc>
< (@korken89:matrix.org)> * features, as pulling in a HAL via a feature and not feature gating the interrupt registration would break as soon as the HAL is no longer in scope I think
<re_irc>
< (@korken89:matrix.org)> Unless the user puts the interrupt registration in its own "mod" like
<re_irc>
< (@korken89:matrix.org)> : Could you expand on the though you had on supporting N:1? I was trying to come up with an example of that to work on the idea with but I was not able to
<re_irc>
< (@korken89:matrix.org)> Do you have any example of that so I can understand the use-case better?
<re_irc>
< (@grantm11235:matrix.org)> If it wasn't for the sharing, could the pac hand out the tokens in "take"?
Lumpio- has quit [Ping timeout: 255 seconds]
<re_irc>
< (@grantm11235:matrix.org)> Does the interrupt handler get set when "register_interrupt!" is called, or is it set in "hal::Spi::new"?
<re_irc>
< (@korken89:matrix.org)> : No really as you as the user need to connect to the correct HAL callback
<re_irc>
< (@korken89:matrix.org)> It could be done in the HAL though if one did not care about the eager interrupt allocation
<re_irc>
< (@korken89:matrix.org)> : In "register_interrupt!"
<re_irc>
< (@grantm11235:matrix.org)> A while back I was prototyping a design where the handler doesn't get set until "hal::Spi::new". This has the advantage that you can set a different handler in "hal::Spi::new_circular", for example
<re_irc>
< (@korken89:matrix.org)> This you can still to with indirection in the driver
<re_irc>
< (@korken89:matrix.org)> The previous take at "cortex-m-interrupt" had it with indirection built in
<re_irc>
< (@korken89:matrix.org)> But that's the exception, not the norm
<re_irc>
< (@korken89:matrix.org)> So we make it compile time instead, and HAL authors can add indirection if needed
Lumpio- has joined #rust-embedded
<re_irc>
< (@korken89:matrix.org)> Or you have a flag to tell the callback which mode it is operating it
<re_irc>
< (@korken89:matrix.org)> I think that would be a lot easier than adding indirection
<re_irc>
< (@korken89:matrix.org)> Or you have a flag to tell the callback which mode it is operating in
<re_irc>
< (@grantm11235:matrix.org)> My plan involved putting the interrupt vector table in ram. Does that use up too much ram?
<re_irc>
< (@korken89:matrix.org)> Only your application can decide taht
<re_irc>
< (@korken89:matrix.org)> * that
<re_irc>
< (@korken89:matrix.org)> But to my experience it's not the norm at least
<re_irc>
< (@korken89:matrix.org)> -at least
<re_irc>
< (@korken89:matrix.org)> Why would you want the entire vector table in RAM btw? Are you doing a lot of flash operations and wants interrupts to continue working while the flash is erased/written?
<re_irc>
< (@grantm11235:matrix.org)> Because it would allow dynamic interrupt handlers without any indirection
<re_irc>
< (@grantm11235:matrix.org)> And it would make the ergonomics really nice. The pac would give you interrupt tokens, and then you just pass the relevant one to "hal::Spi::new"
<re_irc>
< (@grantm11235:matrix.org)> Sharing could be done by statically allocating an array of atomic function pointers and creating a handler that calls each pointer in turn. Each of those pointers would become a new interrupt token. The ergomomics of that aren't quite as nice, but I think it could be done without macros
<re_irc>
< (@korken89:matrix.org)> Sure, but to me that'd be a special case use-case for when it can be afforded
<re_irc>
< (@korken89:matrix.org)> Also if the token is generated by cortex-m it can't do half of the compile time error checking, it looks like you'd have to go to runtime error checking instead
<re_irc>
< (@korken89:matrix.org)> Unless one were to come up with a different way than to have the proc-macro check the driver
<re_irc>
< (@grantm11235:matrix.org)> Checking for what?
<re_irc>
< (@korken89:matrix.org)> This part Sounds like a
<re_irc>
< (@korken89:matrix.org)> Plus you get errors that point to the right line in code
<re_irc>
< (@korken89:matrix.org)> I've answered enough "weird compiler errors that don't explain what you need to do"-questions in my days now to really put that at the top of my list :P
<re_irc>
< (@grantm11235:matrix.org)> I'm still not sure I understand what checking is needed. Under my plan, all handlers are noops at startup, they only get registered after you give a token to the hal (or register your own handler manually). The hal just needs to only accept the correct type of token
<re_irc>
< (@korken89:matrix.org)> This is the same, just that they are not noops
<re_irc>
< (@korken89:matrix.org)> It's up to the HAL implementer to make the "on_interrupt" do the right thing after the driver is enabled
<re_irc>
< (@korken89:matrix.org)> Before that it does not really matter as the IRQ is not enabled
hwj has quit [Ping timeout: 260 seconds]
<re_irc>
< (@korken89:matrix.org)> Plus the "on_interrupt" is safe as you require "unsafe" code to unmask the interrupt
<re_irc>
< (@grantm11235:matrix.org)> The other half of the checking is just to check for typos in the call to "register_interrupt!", right?
<re_irc>
< (@grantm11235:matrix.org)> Under my plan, there wouldn't be a macro, it would just be "let p = pac::take()?; let spi = hal::Spi::new(p.spi1, p.interrupts.spi1);"
<re_irc>
< (@korken89:matrix.org)> The 2 error checking mechanisms are:
<re_irc>
1. The proc-macro checks that you generate a token for a HAL driver that can use said token (early errors with correct line to fix)
<re_irc>
2. The trait in the HALs check that you gave it the correct token (late error for when you have the wrong token to the driver)
<re_irc>
< (@grantm11235:matrix.org)> So if you do "hal::Spi::new(p.spi1, p.interrupts.uart2)", it would tell you that you gave it the wrong interrupt because the type is wrong. What else is there to check?
<re_irc>
< (@korken89:matrix.org)> That is indeed condition 2
<re_irc>
< (@korken89:matrix.org)> Not sure I see what you are getting at though
<re_irc>
< (@korken89:matrix.org)> I mean, sure you can make this RAM based
<re_irc>
< (@korken89:matrix.org)> It won't work on an M0 (without +) and you need to pay for the table in RAM and in Flash, and you need to remake how PACs are generated to follow this
<re_irc>
< (@korken89:matrix.org)> So I don't see the upswing with the approach
<re_irc>
< (@korken89:matrix.org)> I'm also not sure how this would work in multi-HAL binaries, but that would probably need testing to fully understand
<re_irc>
< (@korken89:matrix.org)> Sufficient "#[cfg(...)]"ing should probably solve it though
<re_irc>
< (@grantm11235:matrix.org)> I think it would work fine with multiple hals, it would just look like "let spi1 = hal1::Spi::new(p.spi1, p.interrupts.spi1); let uart2 = hal2::Uart::new(p.uart2, p.interrupts.uart2);"
<re_irc>
< (@korken89:matrix.org)> Probably
<re_irc>
< (@korken89:matrix.org)> Another issue is that this approach will eagerly take interrupts
<re_irc>
< (@korken89:matrix.org)> This would not be compatible with frameworks such as RTIC
<re_irc>
< (@grantm11235:matrix.org)> I think it would be pretty good overall, except for the ram usage, which sounds like a dealbreaker for general purpose use
<re_irc>
< (@grantm11235:matrix.org)> Could RTIC be made to work with tokens?
<re_irc>
< (@grantm11235:matrix.org)> By the way, what is the M0 non-plus problem? Does it not allow you to change the location of the vector table?
<re_irc>
< (@9names:matrix.org)> no vtor register, yep
<re_irc>
< (@korken89:matrix.org)> : Correct
<re_irc>
< (@korken89:matrix.org)> : Probably, but it would be a large undertaking
<re_irc>
< (@korken89:matrix.org)> But if the ecosystem would go there, RTIC would follow
<re_irc>
< (@grantm11235:matrix.org)> I remain convinced that I could find a solution to any problem with my plan, except the ram usage which is the biggest problem of all. Oh well, lol
<re_irc>
< (@grantm11235:matrix.org)> : Changing topics a bit, is this still sound when there are multiple handlers registered to the same interrupt?
richardeoin has quit [Ping timeout: 260 seconds]
richardeoin has joined #rust-embedded
<re_irc>
< (@dirbaio:matrix.org)> : the use case is: sometimes a peripheral has multiple interrupt signals, which sometimes are merged into a single irq and sometimes not
<re_irc>
< (@dirbaio:matrix.org)> for example, STM32 timers have 5 signals: BRK, CC, COM, TRG, UP
<re_irc>
< (@dirbaio:matrix.org)> so if you want to write a "timer driver" that handles all 5 signals, you'd need it to take 4 tokens for TIM1, 1 token for TIM2
<re_irc>
< (@dirbaio:matrix.org)> which would need a giant cfg/macro mess
<re_irc>
< (@dirbaio:matrix.org)> this changes across chips too, for example STM32G0C1VE TIM1 separates only CC...
<re_irc>
< (@korken89:matrix.org)> It can have any name
explore has joined #rust-embedded
<re_irc>
< (@korken89:matrix.org)> The user only needs to follow the example/docs then
<re_irc>
< (@dirbaio:matrix.org)> if the user did
<re_irc>
hal::tim1::register_interrupts!();
<re_irc>
hal::tim11::register_interrupts!()
<re_irc>
< (@dirbaio:matrix.org)> they'd get a conflict on TIM1_TRG_COM_TIM11
<re_irc>
< (@dirbaio:matrix.org)> :S
<re_irc>
< (@dirbaio:matrix.org)> it has to be a single macro call for N peripherals
<re_irc>
< (@dirbaio:matrix.org)> and the macro has to be "smart" so that if you ask for TIM1+TIM11 then it creates a single handler for TIM1_TRG_COM_TIM11 that calls both tim1 and tim11 "on_interrupt"s
<re_irc>
< (@dirbaio:matrix.org)> 😭
<re_irc>
< (@korken89:matrix.org)> Is there some reason to not register both?
<re_irc>
< (@korken89:matrix.org)> I mean, can't the "on_interrupt" for the unused timer be a noop if it is not used?
<re_irc>
< (@dirbaio:matrix.org)> if you ask for TIM1 only you don't want TIM11 bloat in your binary
<re_irc>
< (@dirbaio:matrix.org)> perhaps for timers it's not that bad
<re_irc>
< (@dirbaio:matrix.org)> but some irqs are shared between completely unrelated peripherals too
<re_irc>
< (@korken89:matrix.org)> Right
<re_irc>
< (@korken89:matrix.org)> Though at least they'll get an error, so it will be highlighted that something is wrong
<re_irc>
< (@korken89:matrix.org)> But not a very helpful error message
<re_irc>
< (@dirbaio:matrix.org)> yea... but there _has_ to be some way to use TIM1+TIM11
<re_irc>
< (@korken89:matrix.org)> In this concept it would be to have a combo macro that registers for both
<re_irc>
< (@korken89:matrix.org)> Not super for the HAL author maybe
<re_irc>
< (@korken89:matrix.org)> It seems to me that the base registration macro is powerful enough, the question lies now in how to make it easier for the user via the HAL
<re_irc>
< (@korken89:matrix.org)> In the end I assume we want a simple thing the user can copy-paste from the HAL to make it all work
<re_irc>
< (@korken89:matrix.org)> Preferably would be to not even need that, but yeah
<re_irc>
< (@korken89:matrix.org)> : Does it need to be smart? As the user will get an error from the macro saying this is duplicated, it seems to me that it should be enough info to at least check the example/docs again
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #rust-embedded
<re_irc>
< (@dirbaio:matrix.org)> : I mean, if you do
<re_irc>
Here's another thing I'm wondering about: For SoCs, it happens ever so often that the same peripheral blocks are found in different chips, potentially across vendors, though at diffferent addresses etc.. The corresponding PAC would encapsulate that, and we can just pass on from PAC to HAL, right? Would it make sense to be able to compose a HAL based on, say, Denali DRAM controller variant/version whatever, at address X, plus SPI...
<re_irc>
... from Synopsis at address Y, UART from whoever at address Z, and so on, or am I overthinking it? I guess that could be an issue with how PACs are written / generated? Or is there a common way of accessing the peripherals that everyone adheres to, such that HALs need no duplication?
<re_irc>
< (@matoushybl:matrix.org)> Regarding the sharing of code for peripherals on different addresses - the bxcan crate does something like that: https://github.com/stm32-rs/bxcan also embassy-stm32 has pac for peripherals, where a single peripheral definition is shared across chips and families
<re_irc>
< (@chemicstry:matrix.org)> I was having a similar idea when doing baremetal on raspberry pi. The synopsys pl011 uart is present on many SoCs and could be reused instead of packing into a single HAL. And in case of bootloader, you probably want to load peripherals and their addresses from device tree? Or is that only used for the upper boot stages?
<re_irc>
< (@dirbaio:matrix.org)> i'm not a fan of the bxcan way (this trait (https://github.com/stm32-rs/bxcan/blob/master/src/lib.rs#L76-L79)) because if you have 2 instances of the same peripheral, you HAVE to create 2 types one for each address, and then instantiate the driver with both as generic params
<re_irc>
< (@dirbaio:matrix.org)> if you instantiate the same driver twice with different generic params, the compiler monomorphizes the entire driver for each one
<re_irc>
< (@dirbaio:matrix.org)> so your code size is now DOUBLED
<re_irc>
< (@dirbaio:matrix.org)> this is the case too for many HALs ("Uart<UART1>, Uart<UART2>" also causes duplication like that)
<re_irc>
< (@dirbaio:matrix.org)> I think the future is passing the peripheral address at runtime, so no monomorphization is needed
<cr1901>
I have a solution to critical section bloat. I'm not proud of it, but it works
<re_irc>
< (@henrik_alser:matrix.org)> Sup nerds
<re_irc>
< (@adamgreig:matrix.org)> ok, let's start! a few releases this week, alloc-cortex-m to update linked-list-allocator to fix an issue there, svd2rust 0.27.2 (https://github.com/rust-embedded/svd2rust/blob/master/CHANGELOG.md#v0272---2022-11-06), riscv-rt 0.10 with a fix in link.x for latest stable rust, and the cortex-a crate is now known as aarch64-cpu and has released v9.0
<re_irc>
< (@adamgreig:matrix.org)> , do you wanna talk about cortex-m-interrupt?
<re_irc>
< (@korken89:matrix.org)> Sure!
<re_irc>
< (@korken89:matrix.org)> There has been a lot of feedback, and in that feedback and I have come up with a syntax that allows for registering both simple and very complex (read STM32 TIM1) driver to interrupts
<re_irc>
< (@korken89:matrix.org)> syntax + working codegen
<re_irc>
< (@korken89:matrix.org)> In the end I simplified the macro a lot as well
<re_irc>
< (@korken89:matrix.org)> Where we show from very simple registration to very complex, plus that it works with exceptions as well
<re_irc>
< (@korken89:matrix.org)> The difference now is that this is 100% compile time and no indirection
<re_irc>
< (@korken89:matrix.org)> Plus that all driver relationships are checked at compile time as before
<re_irc>
< (@korken89:matrix.org)> So, more or less fix issues that came with the feedback :)
<re_irc>
< (@adamgreig:matrix.org)> nice! and it also avoids the weird scoping issue cortex-m-rt has with its macro and needing to have imported interrupt from the pac directly?
<re_irc>
< (@korken89:matrix.org)> It only needs local import
<re_irc>
< (@korken89:matrix.org)> So if you have "use hal::pac::Interrupt;" and then use "Interrupt::Enum" in the macro everything works as expected
<re_irc>
< (@korken89:matrix.org)> I see the example does not do a good job there
<re_irc>
< (@korken89:matrix.org)> I use a lot of full paths
<re_irc>
< (@korken89:matrix.org)> I'll update that after the meeting to show it better
<re_irc>
< (@korken89:matrix.org)> I just need to fix docs and cleanup and I'll merge this into master and make a release so it can be tested by others
<re_irc>
< (@korken89:matrix.org)> I hope we get more awesome feedback :)
<re_irc>
< (@korken89:matrix.org)> The issue that is left now is a bit more complex, how to make this registration simpler for the user and HAL authors - but we only have initial ideas there for now
<re_irc>
< (@adamgreig:matrix.org)> sounds good! that you can use full paths at all like that demonstrates that it doesn't suffer cortex-m-rt's interrupt weirdness anyway, it relies on aliasing the interrupt macro and the interrupt enum in the pac
<re_irc>
< (@adamgreig:matrix.org)> do you think it would ever make sense to use the macro to register an interrupt handler directly, i.e. as a replacement for the existing interrupt proc macro?
<re_irc>
< (@adamgreig:matrix.org)> could you pass a closure 🤔
<re_irc>
< (@korken89:matrix.org)> I see the as a bit orthogonal, this is made to register to "drivers" and their API can check that all requirements are upheld
<re_irc>
< (@korken89:matrix.org)> While the old macros is for writing code in them
<re_irc>
< (@korken89:matrix.org)> While you can make a free function, impl the trait and register that though
<re_irc>
< (@korken89:matrix.org)> But I don't thin that's all that ergonomic
<re_irc>
< (@korken89:matrix.org)> Maybe someone will experiment a bit to see how it can be done :D
<re_irc>
< (@korken89:matrix.org)> As it is not the macro is very simple, which is nice
<re_irc>
< (@korken89:matrix.org)> < 200 lines of code all in all
<re_irc>
< (@firefrommoonlight:matrix.org)> PFA re this: I want to be able to feature gate interrupts. This might be an RTIC thing, or may also apply to Cortex-M and beyond. I currently have to comment-in and comment out all lines that have the interrupt name (top line of each ISR) whenever I change MCU-feature
<re_irc>
< (@firefrommoonlight:matrix.org)> The naive way of putting a feature gate before doesn't work
<re_irc>
< (@korken89:matrix.org)> This is not an issue with this approach
<re_irc>
< (@korken89:matrix.org)> It's one of the things I also wanted to fix from the experience with RTIC's feature gating issues
<re_irc>
< (@firefrommoonlight:matrix.org)> It would also be cool if we could move interrupts into the HAL level so that could be handled transparently(sounds like that's what y'all are working on?)
<re_irc>
< (@korken89:matrix.org)> You do the following:
<re_irc>
mod yolo {
<re_irc>
#[cfg(feature = "myfeature")
<re_irc>
register_interrupt!(...)
<re_irc>
}
<re_irc>
< (@firefrommoonlight:matrix.org)> Yea that would be fine
<re_irc>
< (@firefrommoonlight:matrix.org)> My current comment/uncomment approach is awful!
<re_irc>
< (@korken89:matrix.org)> : Not sure if we are thinking about the same
<re_irc>
< (@korken89:matrix.org)> Why we do this and not 100% in the HAL (which is what we'd really do want), is that you get eger interrupt allocation
<re_irc>
< (@korken89:matrix.org)> I'd love if there are some ideas on how to do it so only used interrupts are allocated, but so far I'm coming up empty handed
<re_irc>
< (@firefrommoonlight:matrix.org)> Also, sometimes on Stm32 the interrupts for the same thing will have wildly different and confusing names variant to variant and periphs to periph. I wonder if there's a way we can smooth over that
<re_irc>
< (@korken89:matrix.org)> And this approach is the closest I could come by automatically checking everything, while doing registration in user ciode
<re_irc>
< (@korken89:matrix.org)> * cide
<re_irc>
< (@korken89:matrix.org)> * everything for correctness, while doing registration in user code
<re_irc>
< (@korken89:matrix.org)> So it's does at least make it impossible to get driver to IRQ relations wrong, which is a lot better than what we have today :)
<re_irc>
< (@therealprof:matrix.org)> Sooo slick.
<re_irc>
< (@korken89:matrix.org)> And if one checks the "mod hal" in the example, it's not complex for the HAL author
<re_irc>
< (@korken89:matrix.org)> Which is very important
<re_irc>
< (@korken89:matrix.org)> Both me an though am not super happy with the code the user needs to do to register
<re_irc>
< (@korken89:matrix.org)> We had some ideas that the HAL could have a macro-by-example that just expands into the "correct registration" to help users
<re_irc>
< (@korken89:matrix.org)> But no definitive results here yet
<re_irc>
< (@korken89:matrix.org)> Unless anyone has an idea, ears are all open :D
<re_irc>
< (@korken89:matrix.org)> So this was more an announcement than feedback time, but I hope people will give it a try as soon as we release this for experimentation!
<re_irc>
< (@adamgreig:matrix.org)> sounds good, thanks for the explanation!
<re_irc>
< (@korken89:matrix.org)> And thanks for all the feedback so far!
<re_irc>
< (@adamgreig:matrix.org)> cr1901, do you wanna talk about the c-s stuff?
<cr1901>
Yes, uhhh... I'm not proud of this, but it solves my problem in the interim
<cr1901>
And I was hoping that eventually it would be possible to opt-in to what I've done in a supported way in the critical-section crate
<cr1901>
I patched every use of critical-section to use my version which defines the critical-section implementation in-line, and disable defining "critical-section-single-core" feature provided by the msp430 crate
<cr1901>
This fixes the bloat to my satisfaction, but I... don't like it aesthetically :P
<cr1901>
It feels like I'm grossly misusing the patch feature
<re_irc>
< (@dirbaio:matrix.org)> oof :S
<re_irc>
< (@korken89:matrix.org)> Neat
<cr1901>
Yea... I guess my question is... is there any way to duplicate the behavior in critical-section crate, perhaps with a feature
<re_irc>
< (@dirbaio:matrix.org)> I have a feeling the root of the issue is the inliner hates "extern fn"s, they mess up its heuristics or something
<re_irc>
< (@adamgreig:matrix.org)> basically it means disabling the pluggability and bring-your-own-impl and instead have the c-s crate provide the impl?
<cr1901>
yes lmao
<cr1901>
dirbaio: Yes, but there's been no activity on the bug report I've opened re: it
<re_irc>
< (@dirbaio:matrix.org)> oh you have a link?
<re_irc>
< (@dirbaio:matrix.org)> I had similar issues trying to code-size-optimize defmt
<re_irc>
< (@dirbaio:matrix.org)> it's probably a llvm bug though
<cr1901>
I don't think so, because the bug is present in the emitted LLVM
<cr1901>
>release duplication appears in the LLVM files emitted by rustc.
<re_irc>
< (@dirbaio:matrix.org)> huh, wat
<cr1901>
If you have use cases where the bloat is messing things up, I'd appreciate a comment on the issue to boost its visibility
<cr1901>
In the interim, I'm using my horrible patch for AT2XT; the bloat for the msp430-quickstart examples is minor (or sometimes even nonexistent)
<re_irc>
< (@dirbaio:matrix.org)> iirc this got fixed in defmt by adding a trampoline with "#[inline(never)]"
<cr1901>
Yes, #[inline(never)] hints work as well
<cr1901>
they are not ideal for critical-section enable/disable and can add enough overhead to screw up timing of loops
<re_irc>
< (@dirbaio:matrix.org)> what's the fix then?
<re_irc>
< (@dirbaio:matrix.org)> I mean, the thing can be either inlined or not
<cr1901>
Honor #[inline] and #[inline(always)] hints
<cr1901>
is the fix*
<re_irc>
< (@dirbaio:matrix.org)> you're complaining of bloat due to messed up heuristics always inlining, inline(never) fixes that
<re_irc>
< (@dirbaio:matrix.org)> but you're still saying you want it inlined _some_ of the time?
<cr1901>
No, for some reason I don't understand #[inline(never)], #[inline], and "no annotations" _all generate different code_
<cr1901>
and the "no annotations" version is crap
<cr1901>
(#[inline(always)] == #[inline])
<cr1901>
#[inline] is the behavior I in fact want because it generates not-crap code
<cr1901>
But "extern" won't honor that
<re_irc>
< (@dirbaio:matrix.org)> perhaps some MIR inlining thing? (does rustc do that nowadays?)
<re_irc>
< (@dirbaio:matrix.org)> that doesn't explain why is it broken across crates though
<cr1901>
And #[inline(never)] screws up loop timing, so I have it feature gated for applications where that doesn't matter
<re_irc>
< (@therealprof:matrix.org)> Inlining happens at multiple levels...
<cr1901>
All this is to say, if you needed to add #[inline(never)] to get rid of the bloat in defmt after the critical-section crate change, I'd consider that on-topic
<cr1901>
Because I predict the #[inline(never)] annotation is optimizing differently compared to the better codegen before the critical-section crate was added
<cr1901>
(Also, if other ppl click the "eyes" button on the issue I'd appreciate that :P)
<re_irc>
< (@adamgreig:matrix.org)> what a pain :/ with inlining the problem was it was inlining _too much_ and duplicating the inlined code, right?
<cr1901>
yes
<cr1901>
or rather "without _any_ annotations, the generated code is crap"
<cr1901>
"#[inline] annotations ironically fix the size bloat"
<cr1901>
"#[inline] annotations are not honored on extern"
<cr1901>
"#[inline(never)] also fixes the bloat, but this isn't ideal for all applications"
<cr1901>
^That good enough summary :P?
<re_irc>
< (@adamgreig:matrix.org)> yep thanks 💀
<re_irc>
< (@therealprof:matrix.org)> And of course this is all in -O mode. 😉
<cr1901>
Yes, opt-level="s"
<re_irc>
< (@therealprof:matrix.org)> All different again in dev mode.
<cr1901>
`--release` is implied
<re_irc>
< (@adamgreig:matrix.org)> I wonder if upcoming llvm16 will have any effect 🤔
<re_irc>
< (@adamgreig:matrix.org)> anyway thanks for the update and continued investigation
<cr1901>
Maybe, but Rust is generating bad llvm
<re_irc>
< (@adamgreig:matrix.org)> does anyone have anything else to mention in the last few mins?
<re_irc>
< (@hegza:matrix.org)> We make RISC-V chips and our tooling automatically produces the register maps in SVDs. It's in a weird layout though, with most things being inside clusters :/
<re_irc>
< (@hegza:matrix.org)> (we = university)
<re_irc>
< (@hegza:matrix.org)> I guess it's important enough that I could try fixing it and return to it if it looks sensible
<re_irc>
< (@hegza:matrix.org)> mostly just probing / making sure I'm not insane
<re_irc>
< (@adamgreig:matrix.org)> ah, yea
<re_irc>
< (@adamgreig:matrix.org)> I think typically the svds that get fixed with svdtools don't start out with clusters and mostly people are adding them
<re_irc>
< (@adamgreig:matrix.org)> if you generate the svds yourself, why do you need to use svdtools to edit them in the first place?
<re_irc>
< (@adamgreig:matrix.org)> i think it would be totally reasonable for svdtools to be able to manipulate clusters, but i haven't thought how it'd fit into the yaml syntax, and i don't think it's something that's been needed before now
<re_irc>
< (@adamgreig:matrix.org)> but if you control the tooling that generates the svds, i'd probably prioritise just generating good svds to begin with if you can
<re_irc>
< (@hegza:matrix.org)> The tooling uses IP-XACT natively, we had a junior level MSc. worker write a plugin that converts into SVD quite naively. IP-XACT is a... predecessor(?) to SVD
<re_irc>
< (@hegza:matrix.org)> Thus we do find it easier to make minor edits using svdtools. We do have some initiatives for generating better SVD as well
<re_irc>
< (@hegza:matrix.org)> CMSIS-SVD advertises itself as being IP-XACT inspired if I recall right :)
<re_irc>
< (@hegza:matrix.org)> But I guess that's enough about that :) I got something to work with
<re_irc>
< (@adamgreig:matrix.org)> aah got it, I thought you meant you had custom tooling to generate the svd
<re_irc>
< (@adamgreig:matrix.org)> +from scratch
<re_irc>
< (@adamgreig:matrix.org)> yep that's fair enough then, certainly i'd be open to having it able to manipulate clusters, just don't know if it will fit easily into the syntax or what
<re_irc>
< (@hegza:matrix.org)> Yeah I see. I guess I'd get a better idea of that if I do a trial implementation
<re_irc>
< (@adamgreig:matrix.org)> cool, thanks everyone for the meeting! 👋
<re_irc>
< (@rockboynton:matrix.org)> hi all, when is the next version of cortex-m-rt planned for release?
<re_irc>
< (@adamgreig:matrix.org)> there's no specific plan atm, i think the only bugfix is about using the exception macro fully-qualified, is there something in particular you're waiting for?
<re_irc>
< (@rockboynton:matrix.org)> the "set-vtor" feature :)
<re_irc>
< (@adamgreig:matrix.org)> aah yes
<re_irc>
< (@adamgreig:matrix.org)> I should really have put that in the changelog, hah
<re_irc>
< (@rockboynton:matrix.org)> ofc it's only those 3 lines of assembly I can copy into the pre_init manually and it should be fine
<re_irc>
< (@adamgreig:matrix.org)> I don't think there's any particular reason not to cut a release with what we have now tbh
<re_irc>
< (@rockboynton:matrix.org)> or I was thinking of using my pac to set it instead
<re_irc>
< (@adamgreig:matrix.org)> yea, if we have a c-m-rt release soon your pac could possibly just enable the feature on it
<re_irc>
< (@rockboynton:matrix.org)> no I meant use the pac in the pre_init to do something like
<re_irc>
< (@adamgreig:matrix.org)> recurse collecting the first term into a list?
<re_irc>
< (@adamgreig:matrix.org)> assuming the set of keys is small and known
<re_irc>
< (@dirbaio:matrix.org)> ohh hhmmm
<re_irc>
< (@dirbaio:matrix.org)> it's indeed known. it's the set of all irqs, not sure if that's "small" enough lol
<re_irc>
< (@adamgreig:matrix.org)> cortex-m-rt 0.7.2 published 🎉
<re_irc>
< (@adamgreig:matrix.org)> jeez, not sure if it would work with the set of all irqs lol
<re_irc>
< (@adamgreig:matrix.org)> this is just your trick for cfg_global_asm lol
<re_irc>
< (@dirbaio:matrix.org)> ooh that one 🤣
<re_irc>
< (@dirbaio:matrix.org)> yeah
<re_irc>
< (@dirbaio:matrix.org)> except iterating the list N times, one for each key
<re_irc>
< (@dirbaio:matrix.org)> which you can only do if the set of keys is known upfront, which thankfully in this case it is...
<re_irc>
< (@adamgreig:matrix.org)> I was imagining iterating once but appending to a different position list depending on the key, but maybe you can scan the list n times instead
<re_irc>
< (@dirbaio:matrix.org)> > appending to a different position list depending on the key
<re_irc>
how?
<re_irc>
< (@adamgreig:matrix.org)> didn't think it that far through
<re_irc>
< (@dirbaio:matrix.org)> :D
<re_irc>
< (@dirbaio:matrix.org)> actually
<re_irc>
< (@dirbaio:matrix.org)> with N rules
<re_irc>
< (@dirbaio:matrix.org)> and building the N lists concurrently
<re_irc>
< (@adamgreig:matrix.org)> hm yea, one rule per interrupt to take the head of the list
<re_irc>
< (@adamgreig:matrix.org)> recurses only list-length deep
<re_irc>
< (@dirbaio:matrix.org)> cursed, I love it
<re_irc>
< (@adamgreig:matrix.org)> but do you know the list of interrupts at macro-writing time?
<re_irc>
< (@adamgreig:matrix.org)> i guess if it's for the hal then you do and it's ok
<re_irc>
< (@dirbaio:matrix.org)> yeah
<re_irc>
< (@dirbaio:matrix.org)> the build.rs is already codegening cursed macros, what's one more? :P
<re_irc>
< (@adamgreig:matrix.org)> anything to avoid a proc macro huh
<re_irc>
< (@dirbaio:matrix.org)> the proc macro crate would need a build.rs to codegen it too :S
<re_irc>
< (@adamgreig:matrix.org)> ultra cursed
<re_irc>
< (@dirbaio:matrix.org)> ah no, it can read the stm32-metapac metadata directly
<re_irc>
< (@adamgreig:matrix.org)> it wouldn't need to recurse macro calls to group a list though lol
<re_irc>
< (@adamgreig:matrix.org)> i was hoping it could just read the metadata directly lol
<re_irc>
< (@adamgreig:matrix.org)> if build.rs can codegen the proc macro it seems like the proc macro should be able to codegen itself
<re_irc>
< (@dirbaio:matrix.org)> yeah yeah
<re_irc>
< (@dirbaio:matrix.org)> perhaps declarative macro is the stupid way to do it indeed
<re_irc>
< (@adamgreig:matrix.org)> more fun though
<re_irc>
< (@adamgreig:matrix.org)> and like, how long is the list ever likely to be?
<re_irc>
< (@adamgreig:matrix.org)> it scales pretty bad on c-m-rt if you make each line of assembly its own string, but grouping them into big blocks that you might want to cfg worked fine