sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
fengling has joined #m-labs
cr1901_modern has quit [Ping timeout: 252 seconds]
cr1901_modern has joined #m-labs
<sb0>
xcombelle, thanks!
<sb0>
have you tried it?
<xcombelle>
sb0 I did not hardware thing since the engineer school, 15 years ago but I would love to do. The only problem is that I'm not manual at all, so a board with all ready would be ideal, but I don't know which one choose
<sb0>
maybe pipistrello?
<cr1901_modern>
Pipistrello seems like a decent mid-level board
fengling has quit [Ping timeout: 240 seconds]
<whitequark>
bb-m-labs: force build --props=package=rustc conda-lin64
<bb-m-labs>
build forced [ETA 32m30s]
<bb-m-labs>
I'll give a shout when the build finishes
<sb0>
what do you mean by toolchain? I thought you were able to run a basic "hello world" program already
<whitequark>
yes, but that didn't have rust's stdlib
<whitequark>
so that was just the compiler, not the toolchain
<rjo>
whitequark: no arc?
<whitequark>
rjo: no Arc.
<whitequark>
since OR1K's atomics are pretty broken.
<whitequark>
I could probably hack Rust's stdlib to only use 32-bit atomics, as opposed to all sizes up to 32-bit, in which case they map directly to OR1K's instructions
<rjo>
maybe we can just fix the isa.
<whitequark>
that's an option. are you willing to coordinate this with OR1K people?
<rjo>
potentially willing but probably unqualified
<whitequark>
I can figure out the instruction encoding and *probably* capable of fixing mor1kx
<whitequark>
(the encoding is an annoying issue; there is no nearby hole for 8-bit/16-bit instructions like there was for normal loads and stores, so it'll have to be tucked somewhere else)
<sb0>
if we start to run on modified or1k, we can also clean up the interrupt vector silliness while we're at it
<whitequark>
I think the idea is to run on upstream or1k, but fix the upstream
<rjo>
is it obvious why rust wants 8 and 16 bit atomics?
<whitequark>
yes. the OS-independent standard library defines atomic variants of primitive types. AtomicBool (which is u8). lots of others.
<rjo>
i see. but for Arc just a 32 bit atomic would be sufficient. is that what you mean by hack?
<whitequark>
yes.
<whitequark>
well, actually I just found a less horrible way to do it.
<larsc>
it not that difficult to build a CAS with LL/SC, but if you then use that CAS operation for your other atomic primitives they might get slightly less optimal
<whitequark>
naw, the LLVM backends use the same loop scaffold for all atomic primitives
<whitequark>
rjo: well if OR1K had a constant endianness, that would have been easy
<larsc>
whitequark: ll/sc atomic looks like: do { ll; modify; } while (!sc);, right?
<whitequark>
but it doesn't. it's configurable
<whitequark>
larsc: correct
<rjo>
whitequark: ack
<sb0>
what do we need the atomics for? aren't we going to use solely coroutines?
<sb0>
it that just for the sake of making a complete port?
<whitequark>
for the sake of not hacking up stdlib, removing most possibility of using external code
<whitequark>
rjo: larsc: ok. i found a truly horrifying piece of code in LLVM that implements this stuff for MIPS
<whitequark>
so I think I can adapt that and get it done quickly
<larsc>
whitequark: and if you change that to cas with ll/sc would it be something like: do { load -> old; modify -> modify; ll -> old2; } while (!sc && old2 == old);
<larsc>
modify -> new
<whitequark>
how exactly?
<whitequark>
I don't understand
<larsc>
cas; atomic is do { old = val; modify val; } while (cas val old);
<whitequark>
where does cas come from?
<larsc>
with a load old at the beginning
<larsc>
hardware instruction
<larsc>
compare-and-change
<larsc>
compage-and-save
<larsc>
bah
<whitequark>
or1k doesn't have a CAS...
<larsc>
compare-and-save
<whitequark>
compare-and-swap
<larsc>
right
<larsc>
so you emulate it with ll/sc, as far as I understood
<whitequark>
no
<whitequark>
I emulate every supported atomic with ll/sc
<larsc>
ok
<larsc>
that's what I missed
<larsc>
the way I understood it you have to implement a cmpxchg like operation and then all the other atomics are build from that
<GitHub19>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/v6grF
<GitHub19>
artiq/master 4e3bb01 Sebastien Bourdeauducq: gui/log: support copying entries to clipboard. Closes #280
<key2>
I wonder if I connected it properly regarding the dat_r and dat_w, could someone have a look ?
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
cr1901_modern1 has joined #m-labs
<whitequark>
rjo: I am correctly told on #llvm that the MIPS hack is not sufficient
<whitequark>
because if neighboring data is modified through a non-atomic instruction, the LL/SC loop will overwrite it
cr1901_modern has quit [Ping timeout: 276 seconds]
cr1901_modern1 is now known as cr1901_modern
<cr1901_modern>
(Warning: I'm clueless here) How would neighboring data be modified through a non-atomic instruction before the loop was over? I thought the entire point of an LL/SC loop or anything similar is that it will run to completion, without being interrupted, before doing anything else.
<whitequark>
SMP. interrupt.
<cr1901_modern>
Ahhh, an interrupt is possible after each iteration of the loop (after each LL/SC is done)?
<whitequark>
an interrupt is always possible.
<whitequark>
if you just disabled interrupts you wouldn't need LL/SC (on uniprocessor anyway)
<cr1901_modern>
whitequark: Sorry, sloppy terminology. Yes an interrupt is always possible. What I meant was an interrupt will be acknowledged AFTER the loop, but not during the LL/SC. Is this correct?
<cr1901_modern>
AFTER each iteration*
<whitequark>
no
<cr1901_modern>
Oh... LL/SC isn't a single instruction. My mistake.
<cr1901_modern>
Nevermind, I don't understand what LL/SC does
<rjo>
sb0: i'll be finished with the other two documentation items tonight.
<rjo>
sb0: i am divided how i would implement #40.
<rjo>
sb0: either with the latencies held in the device_db and then applied as part of the TTL* devices.
<rjo>
or with user defined wrapper classes. but those would not have a nice way of holding the values (other than being "hardcoded").
<rjo>
sb0: if you feel you have an idea how to do that (either purely documentation or with a handfull of device_db extensions added), please go ahead.
<rjo>
whitequark: i don't know whether i read that right but i think the kernel just assumes that stuff is always 4 byte aligned and the neighboring data is unused. does rust then assume 1-byte packability for an atomic 8 bit type?
<whitequark>
it does not assume that it won't happen
<whitequark>
indeed, an array of AtomicBool would be closely packed
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
rohitksingh has joined #m-labs
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
<key2>
sb0: hey what was the name of the fancy CPU you told me a couple of days ago ? remember ?
<sb0>
OPA
<sb0>
terpstra/opa
<sb0>
there are irc logs, too
fengling has joined #m-labs
rohitksingh has quit [Ping timeout: 265 seconds]
fengling has quit [Ping timeout: 240 seconds]
rohitksingh has joined #m-labs
fengling has joined #m-labs
mumptai has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
key2 has quit [Ping timeout: 264 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
rohitksingh has quit [Quit: Leaving.]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
mumptai has quit [Remote host closed the connection]