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
<whitequark>
rjo: power-cycled the three boards and the scope
fengling has joined #m-labs
sb0 has quit [Quit: Leaving]
sandeepkr has joined #m-labs
fengling has quit [Ping timeout: 268 seconds]
fengling has joined #m-labs
rohitksingh_work has joined #m-labs
<GitHub102>
[artiq] sbourdeauducq closed pull request #584: language: Add "A" (ampere) as well-known unit for arguments (master...ampere-unit) https://git.io/vPa8i
<GitHub176>
artiq/master e037d16 David Nadlinger: language: Add "A" (ampere) as well-known unit for arguments...
<GitHub176>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vPaya
<whitequark>
sb0: those onchip responses on twitter seem a little incompetent
<cr1901_modern>
Are you talking about the comments under that specific "RT if you want a dev board" tweet?
<whitequark>
I think so
* cr1901_modern
checks again... last I checked it was mainly one troll shitting on what onchip did
<cr1901_modern>
Oh... I see now
<cr1901_modern>
I'm guessing sb0 took a look at the RTL and realized it wasn't pipelined.
<cr1901_modern>
I was batting adding PicoRV32 to MiSoC (because it will fit cleanly in some smaller FPGAs that I have), but that also is not pipelined.
sb0 has joined #m-labs
sandeepkr_ has joined #m-labs
<whitequark>
sb0: I have freed the little box thing from its wooden prison
<whitequark>
whoever nailed that together did a *really* good job. I broke a hammer.
<whitequark>
I should have bought an axe instead.
sandeepkr has quit [Read error: No route to host]
sandeepkr__ has joined #m-labs
sandeepkr_ has quit [Ping timeout: 258 seconds]
sandeepkr__ has quit [Max SendQ exceeded]
sandeepkr__ has joined #m-labs
rohitksingh_wor1 has joined #m-labs
bentley` has quit [Ping timeout: 265 seconds]
rohitksingh_work has quit [Ping timeout: 260 seconds]
bentley` has joined #m-labs
bentley` has quit [Ping timeout: 260 seconds]
mumptai has quit [Remote host closed the connection]
ChanServ has quit [shutting down]
whitequark has quit [*.net *.split]
acathla has quit [*.net *.split]
bb-m-labs has quit [*.net *.split]
sandeepkr__ has quit [*.net *.split]
kyak has quit [*.net *.split]
kuldeep has quit [*.net *.split]
cyrozap has quit [*.net *.split]
jaeckel has quit [*.net *.split]
awallin__ has quit [*.net *.split]
flaviusb has quit [*.net *.split]
hobbes_ has quit [*.net *.split]
gric has quit [*.net *.split]
kristianpaul has quit [*.net *.split]
kmehall_ has quit [*.net *.split]
[florian] has quit [*.net *.split]
stekern has quit [*.net *.split]
Neuron1k has quit [*.net *.split]
balrog has quit [*.net *.split]
sb0 has quit [*.net *.split]
cr1901_modern has quit [*.net *.split]
siruf has quit [*.net *.split]
rjo has quit [*.net *.split]
larsc has quit [*.net *.split]
attie has quit [*.net *.split]
FabM has quit [*.net *.split]
felix_ has quit [*.net *.split]
tmbinc__ has quit [*.net *.split]
ysionneau has quit [*.net *.split]
fengling has quit [*.net *.split]
rohitksingh_wor1 has quit [Write error: Broken pipe]
<GitHub80>
artiq/phaser 78a41ee Robert Jordens: phaser: kc705: syntax
fengling has quit [Ping timeout: 268 seconds]
mithro has joined #m-labs
<rjo>
whitequark: thanks!
fengling has joined #m-labs
fengling has quit [Ping timeout: 268 seconds]
<rjo>
aaaah. what a relief. sync works, pll locks. the chips must have been in a royally fucked up state where "soft" resetting does not help...
<rjo>
_florent_: ^
<sb0>
reset issues seem to be standard fare with ADI chips
<sb0>
the ad9914 is also lousy with reset bugs
<sb0>
we're actually not resetting it at all right now, because reset causes way more problems than it solves
<rjo>
right. but there it's an actual pin. could be different...
fengling has joined #m-labs
<cr1901_modern>
sb0: Thinking more about your pipelining tweets yesterday. Do you think there's a niche for non-pipelined micros such as Beagle's PRUs for real-time tasks? In theory I guess an ASIC implementing the ARTIQ gateware would also be "a pipelined CPU capable of bounded latency for RT tasks"? (ASICs only)
<sb0>
rjo, is it producing the phaser waveforms already?
<sb0>
cr1901_modern, why would you not pipeline it? also pipelining doesn't preclude RT
<cr1901_modern>
sb0: I've been under the impression that pipelining prevents being able to get exact timing for blocks of code. I.e. pipelining-vs-not-pipelining is a "speed vs latency/timing precision" tradeoff
<sb0>
it's not, simply the pipelining model is more complicated
<sb0>
pipelines are fully deterministic
<sb0>
what is not usually is bus latency
<sb0>
but this affects both pipelined and non pipelined designs
<cr1901_modern>
Hmmm, I guess that would be more complicated, especially if you don't know the current "state" of your DRAM when executing a given instruction (use SRAM :P)
<sb0>
there is no disadvantage to pipelining, except it requires a more skillful design
<cr1901_modern>
Well yes, pipelining will NEVER be slower than a non-pipelined design. That much I do remember :P.
<sb0>
sram is slow and expensive
<cr1901_modern>
sram slow? o.0; expensive yes.
<sb0>
and low density
<sb0>
well the qdr stuff or on-chip sram isn't slow, but it's very expensive
<cr1901_modern>
"pipelines are fully deterministic" I've been thinking about this more, and yes I think you're right. I think I'm conflating pipelining, which is deterministic/exact timing can be easily determined, with other things like branch prediction
<sb0>
sram with prices in the ballpark of sdram are puny 30-MHz affairs
<sb0>
and the sdram will be larger
sandeepkr__ has quit [Ping timeout: 268 seconds]
<cr1901_modern>
And if you really JUST wanted something that "just works", you could either use MiSoC's SDRAM controller or the one hamsterworks provides on his website
<cr1901_modern>
Does the or1k core in ARTIQ have branch prediction?
<cr1901_modern>
If so, how do you (more-or-less) guarantee that a function, which will require a branch, will execute in a maximum number of cycles? I suppose you just calculate the worst case (branch prediction gets in your way, pipeline hazard with data from before the branch occurs)?
sandeepkr__ has joined #m-labs
<rjo>
_florent_: the description of SPI_INTFCONFA in the datasheet is wrong... it *always* *only* takes the *first* nibble. bah.
<_florent_>
rjo: so the mirrored bits are not used?
<rjo>
_florent_: if the SPI master does MSB-first, then _only_ the mirrored bits are used.
<_florent_>
rjo: ok, strange...
<rjo>
_florent_: which are denoted read-only...
<rjo>
_florent_: it's a small note on page 23
<rjo>
_florent_: and apparently it uses the four clock cycles of the ignored other nibble to propagate/execute the reset...
<rjo>
... poorly
<_florent_>
rjo: yes, not sure everything is reseted...
<sb0>
rjo, what's the plan for testing pdq3, do you have the hardware?
<rjo>
sb0: i have one here. just need a PS and a scope.
<rjo>
sb0: the phaser stuff should be doing waveforms, just checking everything before. i am scared to crash the scope again.
<_florent_>
rjo: maybe you should ask sb0/whitequark to also add a remote power switch for the KC705/scope :)
<sb0>
fyi I'll be in the lab tomorrow afternoon hkt
<rjo>
_florent_: absolutely. HP calls this "integrated lights out"...
<rjo>
_florent_: i almost did not catch that you have moved the data sink!
<_florent_>
rjo: ah sorry...
<rjo>
_florent_: does the EB work as it is now? or should i rather test just before the EB commit?
<rjo>
_florent_: NP.
<_florent_>
rjo: yes I tested the elastic buffer
<rjo>
_florent_: ack.
<GitHub167>
[artiq] jordens pushed 6 new commits to phaser: https://git.io/vPV6e
<GitHub167>
artiq/phaser 4c7c479 Robert Jordens: ad9154: add mirrored bits
<GitHub167>
artiq/phaser c8e45ae Robert Jordens: phaser: cleanup jesd phy instantiation a bit
<GitHub167>
artiq/phaser 01bfe54 Robert Jordens: phaser: actually enable stpl
<rjo>
anybody else played with slack?
<cr1901_modern>
rjo: It's Garbage
<cr1901_modern>
Bloated, proprietary centralized chat application with a few extras compared to IRC such as file transfer and custom emoji. I will take IRC netsplits any day of the week
<rjo>
ha. what i like so far: really nice github notifications. better than here on irc and nice on the phone as well.
<cr1901_modern>
rjo: Oh, I'm sure there's nicer UI for bots as well. My bias is totally on display for it being centralized alone.
<rjo>
i don't think it's bloated. but yeah. the rest is true.
<cr1901_modern>
rjo: Are you using the desktop app?
<rjo>
"app"?
<cr1901_modern>
application*. Windows has a desktop application solely for connecting to slack channels
<rjo>
then no. just the web interface. i noticed that chrom(e|ium) calls the combination of a special "app" bookmark and an "app" webpage an "app" now.
<cr1901_modern>
Oh ffs... XD
<cr1901_modern>
The web interface is fine in my experience. But I don't really care for having a browser tab open for IRC-like chat. I miss messages too easily
<rjo>
there are those "desktop notifications"
<cr1901_modern>
I never could get those to work in Opera :o
<rjo>
hahahaha... "CERTIFICATION REGARDING INVESTMENT ACTIVITIES IN IRAN". that and the tone almost had me click "report phishing"
<_florent_>
rjo: just got the core working @ 10gbps :)
<rjo>
_florent_: excellent.
<rjo>
_florent_: much chainge? last time you said one lane didn't work and you skipped fsm states.
sandeepkr__ has quit [Ping timeout: 260 seconds]
kuldeep has quit [Ping timeout: 268 seconds]
<_florent_>
rjo: I still have an initialization issue with the transceiver, I have to bypass phalign stage...
kuldeep has joined #m-labs
sandeepkr__ has joined #m-labs
<_florent_>
rjo: but I'm not using the same clocks (since I was using clock x2 due to a configuration issue)
<_florent_>
rjo: and not ILAS is fine, ADI chip keep sync and data are fine on the scope
<_florent_>
and now
<_florent_>
rjo: but I still have to understand this transceiver initialization issue...
<_florent_>
rjo: but I'll cleanup the elastic buffer first
<rjo>
_florent_: ack.
rohitksingh has joined #m-labs
<rjo>
yay. crashed the scope again. seriously, all i did was *IDN?...
sandeepkr__ has quit [Read error: Connection reset by peer]
<sb0>
yeah, slack is meh
<sb0>
and yes, the web client is bloated. at least when loaded in chrome which is itself bloated (but they are talking about a 50% memory usage reduction in the next release...)
<cr1901_modern>
I don't think it's possible to create a non-bloated web browser, tbf. Amount of technologies required to render the average page is too big.
<sb0>
rjo, do you want me to answer this iran investment email?
<rjo>
sb0: yes. thanks!
rohitksingh has quit [Ping timeout: 268 seconds]
<rjo>
_florent_: if I move to 10 GBps line rate, can I just keep the fabric side at 125 MHz and then set converter_data_width=64?
<rjo>
_florent_: or do I have to feed it at 250 as well.
<_florent_>
rjo: the core use the same frequency than the phys
<_florent_>
rjo: so for now you have to use 250MHz
<rjo>
_florent_: ack.
<_florent_>
rjo: but you can use a Converter module before the core for that
<rjo>
_florent_: another thing. f_sysref=(f_data*S)/(K*F). you have it at 1/16 while it should be at 1/32 AFAICT.
<rjo>
_florent_: not that it matters much for now.
kuldeep has quit [Read error: Connection reset by peer]
<_florent_>
rjo: thanks, that was part of the things I still have to check
kuldeep has joined #m-labs
kuldeep has quit [Max SendQ exceeded]
kuldeep has joined #m-labs
<rjo>
anybody who knows 7 series clocking. which primitives can I use to divide a clock? BUFMR, PLL* anything else?
<rjo>
oh BUFR as well.
<sb0>
MMCM
<rjo>
ack.
<rjo>
_florent_: just a quick check: shouldn't GTXInit also be in the "tx" CD?
rohitksingh has joined #m-labs
<sb0>
rjo, no
<sb0>
the transceiver signals are asynchronous
<sb0>
GTXInit includes all CDC and can be placed in any domain
<sb0>
not really CDC, synchronizers
<GitHub59>
[migen] enjoy-digital pushed 1 new commit to master: https://git.io/vPVA8
<rjo>
_florent_: but i don't think it matters much.
<_florent_>
rjo: don't know from where the or_ is imported
<_florent_>
rjo: indeed since all the links receive the same start signal, it will not matters that much, but I'm going to fix that, thanks.
<rjo>
_florent_: and a question about clock domains. the transport is in the user CD which is phy0. why not "sys"/the default domain?
<_florent_>
rjo: and who will provide the sys clock domain?
<rjo>
_florent_: the "user", as usual.
<sb0>
or_ is pollution from "from misoc.interconnect.csr import *"
<rjo>
_florent_: or more to the point, do you not need a CDC for the user's data "sys" to "user"?
<rjo>
... if you do it the way you do it.
<_florent_>
rjo: we could add a cdc in top of transport layer if you want and if you think it's better than having it outside
<rjo>
_florent_: nono. i would think you don't need that if you have the user-facig side of the core at "sys".
<rjo>
_florent_: then the only thing the user has to do is make sure he feeds data at the right frequency. and no CDC necessary because the EBs make all the CDCs.
<_florent_>
rjo: I'm ok to do that, but that means that the user will have to generate "sys" clock from "phy0"
<rjo>
_florent_: asking differently, is there a downside of not making "phy0" the input CD, but whatever the user desires? i.e. "sys"?
<rjo>
_florent_: i don't think so.
<rjo>
_florent_: it's ok if you generate it from refclock.
<_florent_>
rjo: yes if generated from refclock with the same frequency then yes we can do that
<_florent_>
rjo: if you think that's better for you doing it that way, ok to change
<rjo>
_florent_: imho, this is the way to go. otherwise i'd need EBs between the DDS data generating cores (in the RTIO CD which runs at something derived from refclk) and the JESD core.
<_florent_>
rjo: you idea was that the jesd core provided a clock that will be used by the user
<_florent_>
rjo: so that you use this clock for generating the DDS data
<_florent_>
rjo: but yes I see your point
<_florent_>
rjo: and your solution is fine, if it's easier for you, then we can go that way.
<rjo>
_florent_: but the fact that that clock goes through phy0 is at least an unnecessary restriction/jitter source/arbitrary.
<_florent_>
rjo: yes
<rjo>
_florent_: there are a couple other downsides as well. but anyway. i'd be happy to give that change a shot. but i don't know whether i'd introduce more bugs than "features"...
<_florent_>
rjo: I'm going to change that
<rjo>
_florent_: awesome. thanks!
<_florent_>
rjo: I'll do that tomorrow morning, I was going to leave
<rjo>
_florent_: another thing will come in with the sysref thing. you want to sample that with the raw refclk as close to the IBUFDS_GTE2 as possible. you'd have to CDC the sample/counter/lmfc between phy0 and refclk then.
<rjo>
_florent_: ack. that's good.
<rjo>
_florent_: i'll give it a shot anyway... let's see how much i break. ;)
<whitequark>
cr1901_modern: rjo: the slack desktop "application" is based on electron. it is basically just chrome in a fancier wrapping.
<whitequark>
or possibly less fancy wrapping, depending on how you look at it.
<whitequark>
it has the exact same propensity of eating all your RAM.
<rjo>
whitequark: yes. are you in the lab by chance?
<rjo>
whitequark: ah. didn't know about electron.
<whitequark>
not in the lab but will go by tomorrow again.
<whitequark>
esp8266s were sent to the wrong place but i'll just put an arduino there.
<whitequark>
and get an usb hub i guess.
<rjo>
whitequark: thanks. yeah. sorry about that. but i really have no idea what triggers the crashing... alternatively maybe connect a different scope if that has usb or ethernet?
<whitequark>
i have no idea if sb0's scope has even anything documented
<cr1901_modern>
whitequark: Why do you think Chrome/Opera is fast but Slack and Atom aren't?
<cr1901_modern>
I mean, in my experience Opera is actually fairly good at not eating RAM (for inactive webpages) or relinquishing RAM if another application needs it more.
rohitksingh has quit [Quit: Leaving.]
fengling has quit [Ping timeout: 268 seconds]
fengling has joined #m-labs
klickverbot has joined #m-labs
klickverbot has quit [Remote host closed the connection]
klickverbot has joined #m-labs
klickverbot has quit [Remote host closed the connection]
klickverbot has joined #m-labs
klickverbot has quit [Remote host closed the connection]
klickverbot has joined #m-labs
<whitequark>
rjo: I looked at picotcp
<whitequark>
as well as that second tcp library
<whitequark>
I feel like picotcp would be slightly less work, but none of them is obviously inferior to each other
<whitequark>
to decide I would prefer to first know whether we go with GPL or LGPL. I think that will just decide for me which library to use
<rjo>
whitequark: ack. let me forward that pressure to those that want LGPL...
<whitequark>
hm, so other people are patching the runtime too
<whitequark>
wonder how the rust ksupport would affect that
<whitequark>
should we maybe retain the capacity to add C code?.. not sure.
<whitequark>
the C code above is simple enough that it can be translated into Rust almost 1:1
<rjo>
i'd much rather have them merge their changes instead of trying to dual-track this.
<rjo>
whitequark: yes. I'd also expect the C-code to be of that "shim" quality.
<whitequark>
ok, so pure-Rust makes more sense then.
<whitequark>
especially as it's harder to shoot yourself in the foot even in simpler code (e.g. integer conversions)
<rjo>
yes. and it also preemptively confines the proponents of FPU-ARM co-processors. they would include all kinds of weird and wonderful C code.
<whitequark>
proponents of what?
<whitequark>
do you mean people want to replace kernel CPU with an ARM with VFP?
<rjo>
yes. or even better, have the ARM as a co-processor to the FPGA (with the kernels still on OR1K)
<rjo>
more like a weird DSP with DMA access to lots of data from RTIO channels.
<whitequark>
that doesn't sound like it will be made more troublesome
<whitequark>
since it has a fully separate firmware
<whitequark>
I can't say I'm hostile to that idea anyway... as long as I don't have to write code to support it
<rjo>
the firmware needs to get there and the firmware wants to use some API for RTIO data.
<rjo>
sure. same here.
<whitequark>
so a memcpy and an interface for some core.
<whitequark>
that said. you can just rebuild the entire ksupport for arm with vfp too. and the experiments too
<whitequark>
it will probably actually work better than or1k.
<rjo>
there are no good (low latency, flexible...) interfaces to the FPGA fabric for ARM cores -- internal or external.
<whitequark>
ah
<whitequark>
what's the point then?
mumptai has quit [Quit: Verlassend]
<whitequark>
are these CPUs just used to coordinate the system and not do some interesting processing?
<klickverbot>
whitequark: We are definitely anticipating the switch to Rust, and there shouldn't be a lot of code to translate
<klickverbot>
Keeping C support would make a lot of sense, though
<klickverbot>
C and its ABI are the lingua franca, after all, and it seems unwise to give that up strategically (unless, of course, your strategy is to constrain the ecosystem to what m-labs offers, in which case pushing Rust on people might be a good way to do that)
<rjo>
well. the only case where such a hard cpu would make a real difference is a significant amount of math on a big amount of data with a pretty high latency.
<klickverbot>
(Note that this is coming from a language-head who'd rather see all of C eradicated and replaced with D, Rust, or whatever.)
<klickverbot>
To finish cluing you (sb0) in on the TDC core: Chris and I are currently scrambling to get a proof-of-concept experiment done here. We'd definitely like to tidy things up and upstream the code afterwards, but we are not sure when we'll find the time yet.
<whitequark>
klickverbot: Rust supports (almost) all of the C ABI
<rjo>
klickverbot: ;) i don't think we will get rid of C support in artiq. writing the shim layers in rust should not be much of a frustration for a contributor (AFAICT these shim layers would actually not even be needed; rust could just directly expose CSRs etc to the kernels). for other things AFAICT you can always link in your C code.
<klickverbot>
Sure
<whitequark>
klickverbot: I think the only major part missing is vararg support, which is not important
<klickverbot>
But if you removed build system support, etc., it would be more of a hassle than necessary.
<whitequark>
that would be very nice but unfortunately impossible
<whitequark>
since Rust depends on, well, some things in C (mainly the unwinder but also the TCP/IP stack)
<klickverbot>
Okay, seems like we share that sentiment, then ;)
<rjo>
and the BIOS is also still C.
<whitequark>
I imagine misoc will retain the ability to build C indeterminately
<whitequark>
since it's not just used for ARTIQ
<klickverbot>
whitequark: Regarding the TDC core, I actually have a compiler question: For one of the rung extensions, we'd really want two return integers from one function. `TTuple(TInt32, TInt64)` seems to map nicely to `struct Foo { int32_t a; int64_t b;}` (sret and all). Can we sort-of rely on that to keep working? (Deliberate breaking changes notwithstanding.)
<klickverbot>
s/rung/runtime/
<whitequark>
klickverbot: yes. TTuple is equivalent to a structural definition of a C struct
<klickverbot>
It seemed easier to get working than trying how to pass two ints by-pointer
<klickverbot>
Okay, cool
<whitequark>
note that returning it means returning a struct by-value
<klickverbot>
Yep
<whitequark>
this is guaranteed by the ABI and if it doesn't work file a bug
<whitequark>
(but sret should always work these days)
<klickverbot>
Okay, perfect. I wasn't sure how public it was supposed to be.
<klickverbot>
Why would sret ever not work? The or1k ABI couldn't possibly return this in-register, right?
<whitequark>
there used to be sret-related bugs in the ARTIQ compiler
<whitequark>
I think I've fixed all of them
<klickverbot>
Ah, okay, makes sense
<klickverbot>
That's one of the reeeealy annoying corners of LLVM
<whitequark>
but in general sret is one of the toolchain features that tends to have subtle edge cases
<whitequark>
exactly
<klickverbot>
(having to do all the C ABI lowering yourself, that is)
<whitequark>
well, not all
<whitequark>
LLVM does most of it, like register allocation and assignment, but it won't insert any indirections for you
<klickverbot>
Pretty much all. You have to lower everything into an ill-specified "canonical" form of IR which then maps to IR
<klickverbot>
For example, on x86_64 you need to pack structs into ints yourself
<whitequark>
hmm
<klickverbot>
To have multiple members passed in a single register
<klickverbot>
(like struct { int32_t a, b;}, which would just passed be in rdx or whatever)
<whitequark>
oh, didn't know that was in x86_64 ABI
<whitequark>
actually the x86_64 frame lowering does more than necessary
<whitequark>
e.g. it will automatically paper over sret for you, for some reason
<whitequark>
this is actually quite annoying because it hides portability bugs
<klickverbot>
Paper over sret in what sense?
<whitequark>
from what I recall, even if you don't use sret when returning a large struct by value, it does the dance that gets it through memory
<klickverbot>
Oh, didn't realise that
siruf has quit [Ping timeout: 260 seconds]
<whitequark>
the thing is you're still not supposed to do that
<whitequark>
and it might or might not be subtly different from proper sret or something
<whitequark>
I don't know why it even exists
<cr1901_modern>
"Rust supports (almost) all of the C ABI" Which part doesn't it support? And what *is* the C ABI?
<cr1901_modern>
for that matter*
<klickverbot>
whitequark: I've found that the only chance to get things working properly is pretty much to look at what Clang emits on your platform, and then to only deviate from that if you _really_ know what you are doing. Which is even worse than doing things yourself on top of a well-specified interface.
<whitequark>
cr1901_modern: the C ABI for your platform is described in a PDF called "[your platform] C ABI"
<whitequark>
cr1901_modern: and it doesn't support mainly accepting varargs, but also a few attributes that aren't technically in C but widely used, like aligned structs
<cr1901_modern>
whitequark: Okay, just wanted to make sure. I mistook what you were saying as if there's a *single* C ABI :P
<klickverbot>
It does or it doesn't support aligned structs?
<whitequark>
klickverbot: well, if you don't interface with C, it's enough to ensure the same IR on both sides of the function call pretty much (this is the official position)
<whitequark>
still have to do sret
<whitequark>
if you do interface with C, yeah, you look at clang, which is also the official position afaik
<whitequark>
klickverbot: rust doesn't properly support aligned structs. there's an accepted RFC but it is not implemented yet.
<klickverbot>
whitequark: … if you don't interface with C, yes. Unfortunately, every single language under the sun pretty much needs to interface with some OS. :/
<whitequark>
well, go runs syscalls directly ;)
<whitequark>
on linux, anyway, not elsewhere.
<cr1901_modern>
I hope if that RFC is accepted there's a standards-compliant way to disable it
<klickverbot>
And yes, you can also write an unikernel, then you won't need to match an OS's ABI as well xD
<cr1901_modern>
(unlike GCC __pack
<whitequark>
huh?
<whitequark>
there's already #[repr(packed)]
<cr1901_modern>
Ahhh
<whitequark>
I'm talking about #[repr(aligned("8"))] or something
kuldeep has quit [Ping timeout: 258 seconds]
siruf has joined #m-labs
sandeepkr has quit [Ping timeout: 268 seconds]
<cr1901_modern>
then what does Rust currently do? Just choose the "best alignment"?
<whitequark>
chooses the natural alignment of the struct
<whitequark>
that won't change, of course; you'll just be able to overalign structs explicitly
<cr1901_modern>
Okay I understand now. C ABIs tend to support overalignment even though the spec doesn't require it
<whitequark>
it's not really a part of C ABI but it is a part of real-world C code
<whitequark>
and sometimes a part of platform ABI, like on Windows
klickverbot has quit [Ping timeout: 260 seconds]
sandeepkr has joined #m-labs
kuldeep has joined #m-labs
klickverbot has joined #m-labs
klickverbot has quit [Read error: Connection reset by peer]
klickverbot has joined #m-labs
klickverbot has quit [Read error: Connection reset by peer]