<whitequark>
you need #[no_mangle] on all those extern symbols
<whitequark>
and the static mut NOW should be pub
<sb0>
whitequark: what about sym_ent above in the firmware?
<sb0>
whitequark: yeah there are a few things to polish
<whitequark>
why would anything need to be done with sym_ent?
<whitequark>
you don't have any rela relocations in that binary, but you can't have a binary without symbols
<sb0>
ok
<whitequark>
also if you make NOW pub then it'll go away anyway
<sb0>
whitequark: okay that works, thanks!
<sb0>
do you want to commit it?
<whitequark>
done
m4ssi has joined #m-labs
<mtrbot-ml_>
[mattermost] <sb10q> @astro are you absolutely certain that the MMU is required to use Ethernet on Zynq? Chris went quite far (only ARTIQ though) without messing with it AFAIK
<mtrbot-ml_>
[mattermost] <sb10q> why do you need unaligned accesses?
zignig has quit [Quit: Lost terminal]
zignig has joined #m-labs
sb0 has quit [Quit: Leaving]
_whitelogger has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
proteusguy has quit [Remote host closed the connection]
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 268 seconds]
rohitksingh has joined #m-labs
lynxis has quit [Remote host closed the connection]
<mtrbot-ml_>
[mattermost] <astro> I have really tried hard and for too long to go without mmu
<mtrbot-ml_>
[mattermost] <astro> vaguely related: I wish we could build nightly rust from its source repo, possibly with some experimental patches
<mtrbot-ml_>
[mattermost] <astro> then it might be possible to disable unaligned access in a rust/llvm target definition
<mtrbot-ml_>
[mattermost] <sb10q> so the source of the issue is rust/llvm does unaligned accesses and this requires a MMU? Why is it not a problem on the stm32?
<mtrbot-ml_>
[mattermost] <sb10q> @hartytp is there any clear technical advantage to sensors like the ad590 (seems to be what many people are using) in a ECDL or can I just use a low cost thermistor?
<mtrbot-ml_>
[mattermost] <astro> different target triple
<mtrbot-ml_>
[mattermost] <astro> I have just tried with one that includes features: +strict-align
<mtrbot-ml_>
[mattermost] <astro> fails in other ways now, investigating...
<mtrbot-ml_>
[mattermost] <sb10q> Well the correct way is the path of least resistance, MMU or compiler patch
<mtrbot-ml_>
[mattermost] <sb10q> if we turn on the MMU will it get in the way later e.g. when trying to interface with the FPGA design?
<mtrbot-ml_>
[mattermost] <astro> ...nope, problems at unaligned access again
<mtrbot-ml_>
[mattermost] <sb10q> can't we just compile with the stm32 target triple?
<mtrbot-ml_>
[mattermost] <astro> might work, but it would just not be right, right?
<mtrbot-ml_>
[mattermost] <astro> the compiler will apply the wrong optimizations
<mtrbot-ml_>
[mattermost] <sb10q> also is the MMU reducing performance in any way? Those unaligned accesses sound like they would take multiple bus cycles instead of one
<mtrbot-ml_>
[mattermost] <astro> we'd never shoot down the TLB
<mtrbot-ml_>
[mattermost] <sb10q> OK do it's just loaded once at startup and stays in the processor core?
<mtrbot-ml_>
[mattermost] <astro> exactly
<mtrbot-ml_>
[mattermost] <sb10q> OK, that sounds acceptable
<mtrbot-ml_>
[mattermost] <sb10q> And it's just a TLB for the CPU core, right? There is no funny business with the FPGA interfacing
<mtrbot-ml_>
[mattermost] <astro> it's no IOMMU
<mtrbot-ml_>
[mattermost] <astro> really just in the CPU core
<mtrbot-ml_>
[mattermost] <sb10q> Ok
<mtrbot-ml_>
[mattermost] <sb10q> why is llvm doing those unaligned accesses in the first place? They do seem slow. Or is the CPU cache good at handling them or something?
<whitequark>
making unaligned accesses in software is also slow
<whitequark>
since you need more instructions
<mtrbot-ml_>
[mattermost] <astro> they happen when I read the u8s in a mac address `[u8; 6]`
<mtrbot-ml_>
[mattermost] <astro> they happen in some clever optimization for printing decimal numbers in core::fmt
<whitequark>
unaligned access into dcache is 2 cycles max, but if you do this with instructions i think you need a shift and a mask, which is worse
<mtrbot-ml_>
[mattermost] <astro> it's really hard to eliminate them all over the place
<mtrbot-ml_>
[mattermost] <astro> I would have hoped to avoid them by target spec, but no
<mtrbot-ml_>
[mattermost] <sb10q> yeah sure, I get that if you do need an unaligned access then doing it in hardware is faster, but I'm surprised they are needed
<whitequark>
unaligned accesses are required each time you have a packed data structure
<whitequark>
which happens each time you have an array of anything under a word size
<mtrbot-ml_>
[mattermost] <sb10q> Hmm yes, but what is often done here is to align each member of the structure
<mtrbot-ml_>
[mattermost] <astro> you'll optimize that in the paths that have to be fast
<mtrbot-ml_>
[mattermost] <astro> today I have tried to get a `#[repr(align(16384))]` but it just won't work although it is supposed to do up to 2^31. it would have been prettier than doing it by linker script.