<whitequark>
rust isn't ergonomic on targets without parallelism or when you use lots of global data, and it's designed to be used with code generation
<whitequark>
the new rust runtime for artiq is quite bloated
<whitequark>
it's not really any sort of problem, except annoying load times, but I can see how this could be a large problem on e.g. AVRs
<whitequark>
(I also think the Rsut AVR port is a total waste of time)
<cr1901_modern>
Well, Rust doesn't have much utility for me if there isn't a port to < 32 bit targets, since any language under the sun made today targets them just fine (by proxy of LLVM)
<whitequark>
writing code for non-32-bit targets today is a total waste of time anyway.
<cr1901_modern>
That's what I was afraid you'd say... as much as I love NXP micros (and disdain ARM), 32 bit is complete overkill for small tasks.
<whitequark>
no such thing
<whitequark>
it's cheaper than 8-bit usually and consumes less power
<whitequark>
the bitness itself is a footnote
<whitequark>
anyway, mainline LLVM has two <32 bit targets (MSP430 and AVR) and actually almost nothing that uses LLVM can target any of those.
<whitequark>
in fact I doubt the MSP430 target has ever been used by anyone for anything useful
<cr1901_modern>
MSP430 port is a joke, far as I can tell
<cr1901_modern>
so I don't really count it
<whitequark>
it's not a joke, it works and is maintained, but it was written as an example
<whitequark>
the problem is software on top of llvm. llvm is not enough
<whitequark>
the majority of languages with llvm on backend can't compile for pointer widths <32
<whitequark>
I *think* clang has msp430 support actually
<cr1901_modern>
I suppose the main problem is "nobody cares about < 32 bit targets". And Rust solved that problem with the AVR port, Idk how, but it wouldn't work if it didn't.
<whitequark>
I don't believe you can actually write idiomatic Rust for AVRs
<whitequark>
AVR code generated for HLLs is already very bloated, even for C, and they have very little flash and even less RAM
<cr1901_modern>
The idea in my head was that "If LLVM is very ill-suited for dealing with lots of globals", maybe the MIR backend could handle it better. Or is that the same problem? Expects everything in registers or on a stacl?
<cr1901_modern>
I really don't care about the parallelism problem, personally
<cr1901_modern>
Can't speak for you, but the more deeply embedded the target, the more globals I end up using :/
<whitequark>
this is not an LLVM problem, this is a Rust problem
<whitequark>
static muts are unsafe
<cr1901_modern>
Oh...
<cr1901_modern>
I understand now
<whitequark>
and in fact it's directly related to parallelism. they are unsafe because they indeed are on targets with parallelism
<whitequark>
putting stuff on stack and passing it around bloats already bloated code even more
<cr1901_modern>
And you'll need the stack except for leaf fcns IIRC
<cr1901_modern>
If I'm working on a single-threaded program for an NXP micro that I have, single core, 4k flash, 1k RAM, does the static mut problem still apply?
<whitequark>
yes, obviously
<whitequark>
rustc doesn't care that it's single-threaded
<whitequark>
also 4k flash lol
<cr1901_modern>
That was my follow up.
<whitequark>
good luck getting *anywhere* with rust
<cr1901_modern>
It's the smallest ARM micro that exists
<whitequark>
i think you blow like 20k just by using format_args! once
<cr1901_modern>
Well, tbh, I only really got it b/c it's a DIP package, but it's still cute :3.
<cr1901_modern>
"rustc doesn't care that it's single-threaded" That was my follow up. I thought there was a way to tell rustc that it was single threaded/relax assumptions. But that doesn't work for ISRs, would it?
<whitequark>
i really don't see any point in dip packages either. 0.5 tqfp is trivial to solder with an indented tip and some flux. much less anything larger still.
<cr1901_modern>
I'm working on it :)
<cr1901_modern>
But it's what I have on hand, so I used it for a contrived example
<whitequark>
isrs can't lock or something anyway
<whitequark>
you can get away by mandating isrs to be unsafe
<whitequark>
the problem here is if you have a function called from both "main" and "isr" that's poking a static mut
<whitequark>
rust would have to grow a call graph analyzer
<whitequark>
LLVM is also not that good at whole-program optimization, for example it doesn't try (almost) at all to lift globals
<whitequark>
this actually hits ARTIQ kernels
<whitequark>
neither LLVM nor Rust are designed to emit code for these very small targets, LLVM much less so than Rust but still
<cr1901_modern>
Not a snarky q, but... write a pass for it?
<whitequark>
meh
<whitequark>
I could also complain that LLVM doesn't generate good code for PDP-7
<cr1901_modern>
Well, LLVM has no concept of a 18 bit char so :P
<whitequark>
no
<cr1901_modern>
Unless their wiki is out of date and somebody added it XD
<whitequark>
the problem is that its calling convention is not reentrant
<whitequark>
and there's really no way to make a stack
<whitequark>
18-bit bytes are like, minor, merely a massive amount of assumptions in LLVM
<whitequark>
it's designed to run self-modifying code exclusively, and that *really* doesn't make for easy codegen
<cr1901_modern>
It probably is bad for manual assembly too lmao :P
* cr1901_modern
is poor at reasoning about SMC, looking at old DOS viruses that did that stuff
<cr1901_modern>
"isrs can't lock or something anyway" <--- can you elaborate? Why is "unsafe" insufficient for things that can lock?
<whitequark>
well for example the call instruction stores the return address in the 1st byte of the function
<cr1901_modern>
oh, sorry
<cr1901_modern>
So each fcn has to start with a "NOP"
<whitequark>
it jumps to the 2nd then
<whitequark>
in a loop, the induction variable resides *inside* of the code of the loop
<whitequark>
i.e. you use the increment insn to increment the immediate in the cmp instruction
<cr1901_modern>
And gets modified each iteration, doesn't it?
<whitequark>
kinda nutty
<cr1901_modern>
Sounds like a fun arch to emulate as well, considering how bad WX is today
<whitequark>
there's absolutely nothing hard about emulating it
<whitequark>
it has like 8 basic instructions
<whitequark>
and a few I/O ones
<whitequark>
pretty sure I could write an emulator in a tweet if I really tried and used perl
calle_ has joined #m-labs
<cr1901_modern>
In any case, I think I should just abandon "portable code between 32 bit and smaller archs, even micros" altogether. When C is finally replaced, optimizing for space/limited resources below a specific threshold will be a thing of the past.
<cr1901_modern>
The bloat bugs me. And I know it shouldn't b/c ppl who write code generators know what they're doing.
<cr1901_modern>
sb0: If I want to add custom firmware to MiSoC that gets booted after the BIOS runs, it's sufficient to just add the directory with the relevant Makefile using "add_software_packages"? Is there anything in MiSoC to enable ROM_BOOT_ADDRESS in place of FLASH_BOOT_ADDRESS?
<cr1901_modern>
grepping suggests that ROM_BOOT_ADDRESS can't be enabled without a manual define
rohitksingh has joined #m-labs
calle_ has quit [Quit: Leaving]
sb0 has joined #m-labs
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
stekern_ has quit [Ping timeout: 244 seconds]
stekern has joined #m-labs
sb0 has quit [Quit: Leaving]
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
mumptai has joined #m-labs
<mumptai>
hi
<mumptai>
is there a good way to combine vhdl IPs with migen? I see a couple of things which look not optimal
<mumptai>
i need a mixed language sim. i need to wrap each vhdl to have a verilog compatible port definition
<mumptai>
and if i understand the situation i can't use the migen simulation, but have to export everything to verilog and build a verilog testbench?