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
antgreen has joined #m-labs
<sb0_>
cr1901_modern, linux is not a hobbyist OS.
<sb0_>
also, there's no black magic involved in developing a OS
<sb0_>
the main difficulties are
<sb0_>
1) maintaining halfway decent hardware compatibility in the age of trainwrecks like USB, ACPI, etc. - this requires no more and no less than an army of testers and fixers
<sb0_>
2) having people port/package stuff for that OS, which is a critical mass problem
<sb0_>
those are wetware, not technical, issues
<sb0_>
whitequark, I think that lisp machine stuff is much superior than MMUs and privilege levels...
<whitequark>
two different ways to get memory safety
<whitequark>
I find them equivalent, with MMUs being a little bit more flexible
<whitequark>
perhaps it would be nice to have microcoded handling for IPC and get away with kernel mode
<whitequark>
*do away
<whitequark>
sb0_: you will find azonenberg's thesis very interesting, i think
<sb0_>
MMUs are slow when you are context switching or message passing (which you do all the time in microkernels)
<whitequark>
are they really?
<whitequark>
I mean, sure, if you flush TLB every time you change page table root, sure
<whitequark>
x86 doesn't do that. ARMv7 doesn't do that.
<sb0_>
bah, how do you send object X somewhere in memory space of process A to process B?
<whitequark>
the latter uses tagged TLB entries and the former uses some dark magic
<whitequark>
um. remap it?
<whitequark>
that's what Mach does
<sb0_>
share the page(s) containing it? then process B can read data it should not
<sb0_>
copy memory? then it's slow
<whitequark>
allocate at page granularity, copy whatever's smaller than a page
<whitequark>
i am very certain you can copy amounts smaller than a page really, really quickly.
<whitequark>
how about just shuffling cache lines around
<whitequark>
that seems like it would extend MOESI very easily
<sb0_>
then what if object X contains pointers to many other small objects you also want to share?
<sb0_>
let's say you are sending a tree structure
<whitequark>
have you seen how protobuf encodes objects?
<whitequark>
er
<whitequark>
no, not protobuf
<whitequark>
cap'n proto.
<sb0_>
is that an advanced form of memory copy?
<whitequark>
think of it as PIC except for data structures
<whitequark>
while this is a partial solution at best, i think it is also worthwhile to reexamine how much do you *really* need to share large trees
<whitequark>
the workloads which will be a bottleneck in a microkernel is IO. disk IO, network IO. all of that is extremely efficiently handled by remapping pages
<whitequark>
you'd want them to be page-aligned anyway
<sb0_>
well, IPC of a complex structure on a lisp machine is general, straightforward and no hacks needed.
<whitequark>
now, represent a string in a lisp machine efficiently
<whitequark>
i.e. not a series of cells
<sb0_>
cdr coding?
<whitequark>
"no hacks needed"
<whitequark>
there is another issue, which is that trees and linked lists are pretty much worst case cache-wise
<whitequark>
that's just setting yourself up for failure
<whitequark>
was there ever a lisp machine with a cache?
<whitequark>
there are of course more issues, such as "fitting a tracing GC in hardware" and "you can't efficiently implement a queue using immutable cells"
<whitequark>
and
<whitequark>
*and "we want a realtime GC, but then we have to make everything cell-sized and use treadmill"
<sb0_>
you can have a large microcode for the GC, which runs in parallel on a separate "core"
<whitequark>
a parallel GC is a nightmare
<whitequark>
now you need read barriers, write barriers AND safepoints
<mithro>
whitequark: it's actually pretty easy if you get help from the allocator - with fast page remapping you can even do a GC with compaction
<whitequark>
I mean, you can make it work, Azul did it, but it is not pretty
<whitequark>
and certainly not simple
<whitequark>
mithro: I thought the whole point was to get rid of an MMU :D
<sb0_>
hmm, why do you need those barriers? the GC can know what objects are currently loaded in the main core's registers
<mithro>
whitequark: Azul was hampered by the fact that the jvm code is horrible
<whitequark>
sb0_: read barrier is to check whether you are reading a forwarding pointer
<whitequark>
write barrier is to check whether you need to promote an object from younger to older generation
<sb0_>
you want to trace when you are accessing pointers anyway for memory protection reasons
<sb0_>
otherwise, you could cast a cdr coded cell field into a pointer by accessing it incorrectly, and break the system
<whitequark>
mithro: I would argue that most of the hard problems they solved are of more fundamental nature
<sb0_>
it only takes a small extra step to inform the GC that you are reading (and referencing) a pointer
<whitequark>
sb0_: the issue that i would consider most critical is the lack of ability to efficiently cache things
<whitequark>
the rest can probably be eaten by the core, if appropriately engineered
<mithro>
whitequark: their trick of using read only pages to allow moving live objects is pretty cool generally
<whitequark>
and leave just an architectural constraint
<whitequark>
mithro: yup
<whitequark>
lots of really interesting engineering
<whitequark>
also they're adding statepoints to LLVM
<whitequark>
it's cool. i wonder if it would make sense to use these for artiq
sb0_ has quit [Quit: Leaving]
fengling has quit [Ping timeout: 272 seconds]
fengling has joined #m-labs
<GitHub69>
[artiq] fallen pushed 1 new commit to master: http://git.io/vUlim
<GitHub69>
artiq/master fb8ccbd Yann Sionneau: travis: install all conda dependencies at the same time
<cr1901_modern>
sb0_: Linux STARTED as a hobbyist OS. My point was that there will never be another success story like Linux
<cr1901_modern>
And the TLDR version of why I believe that is that modern graphics is too complicated for a small group to be able to create a UI that users will tolerate
<cr1901_modern>
sb0: cc :P
<cr1901_modern>
You could have the most innovative OS in the world in terms of kernel design, but no appreciable userbase will use it if you are stuck having to use VESA gfx modes that give you 4:3 on a 16:9 screen.
fengling has quit [Ping timeout: 265 seconds]
<cr1901_modern>
So it becomes a nasty catch-22: You need ppl to want to develop drivers to get a better UI, but you won't attract new users and potential talent without an good UI to begin with
<whitequark>
you do realize nouveau is FOSS?
<cr1901_modern>
nouveau has a LOOOOOOOOOOOOOONG way to go
<whitequark>
there are projects that even reuse linux's drivers directly, such as genode
<whitequark>
nouveau gives you a framebuffer.
<whitequark>
either way, people write graphics drivers from scratch all the time
<whitequark>
the reverse-engineered PowerVR driver, the reverse-engineered Mali driver
<whitequark>
(both of which, in terms of market share, are probably more important than nvidia)
<whitequark>
and even barring all that, there are plenty of reasons to make an OS which /can't/ drive a display directly
<whitequark>
e.g. mirage or HaLVM (which may or may not be OSes in general sense but people definitely have been calling them OSes)
<cr1901_modern>
I'm not sure what you mean by that last statement, other than the literal interpretation of "screw the UI"
<cr1901_modern>
GUI* even
<whitequark>
servers don't need an UI. embedded systems that aren't smartphones don't have the usual PC-like GPU arrangement
<larsc>
I'm pretty sure that when Linux started out people were giving all kinds of reasons why it can't succeed because it doesn't support feature X
<cr1901_modern>
Hey, I want to be wrong. Admittedly, I'm rather negative, because chances are, I'm not "that person who will succeed when told 'you can't'"
<cr1901_modern>
I'd never heard of Genode before now. A little bit surprised that Linux drivers can be used for it. I guess they provide a kernel API compat layer or something
<whitequark>
yes
<cr1901_modern>
Another project which has legit surprised me is MenuetOS. Except since they closed-source the 64-bit version, I'm hesitant to support it
<whitequark>
if you have enough people who fetishize x86 assembly in one place, something like that is bound to happen
_florent_ has joined #m-labs
<cr1901_modern>
Backwards compatibility is a bitch, aint it? XD
fengling has joined #m-labs
<cr1901_modern>
whitequark: Tagged TLB entries == that Address Space ID?
<cr1901_modern>
s/that//g
<whitequark>
yes
<sb0>
cr1901_modern, popularity doesn't correlate with getting shit done. look at raspberry pi: one of the most hyped geek projects and most of the software developed for it is crap
<sb0>
last time I checked, you needed to edit a text file parsed by a proprietary GPU blob and reboot to change the screen resolution
<cr1901_modern>
Still do. XD
<cr1901_modern>
"one of the most hyped geek projects and most of the software developed for it is crap" <-- that's just Sturgeon's Law in effect though.
<cr1901_modern>
I could be dead wrong. Kinda hope that I am
<sb0>
sturgeon law or not, you could achieve more with a team of 10 talented and motivated developers than the millions of raspberry pi users have done
<cr1901_modern>
Actually, I *really* hope that I am, and that I just have a lot of misconceptions of what hobbyists/small groups are capable of.
<cr1901_modern>
As an aside, one of the things that bothers me re: Raspberry Pi is that the "official OS" requires a custom kernel that cannot be built from a vanilla source tree. NetBSD (which I run on mine) doesn't have that problem tho.
<cr1901_modern>
Can't really pin down why, but that bothers me- it's like the port wasn't done right.
<cr1901_modern>
btw, sb0, question about the Migen manual. When you describe the Instance specials, the fourth bullet point about why to use instance states te following: Breaking down a Migen system into multiple sub-systems >>
<cr1901_modern>
Isn't that what the submodules field is for? Or are you talking about "splitting a Migen design between source files"?
<sb0>
between source files
<sb0>
cr1901_modern, license incompatibilities I would bet
<sb0>
no?
<cr1901_modern>
It's possible. Up until a few weeks ago, I didn't realize how unfriendly Broadcom is to FOSS
<whitequark>
bwahahahaha
<cr1901_modern>
And considering the RPi foundation was founded by someone who works there and likely had help porting from them...
<cr1901_modern>
My first hint was: no pinout, no prices for chips, that I would be shrugged off b/c I'm not ordering tens/hundreds of thousands of units.
<whitequark>
RPi foundation is the charity/marketing arm of Broadcom
<cr1901_modern>
Basically, I was wondering how cheap the BCM2xxx whatever actually is, and wanted to compare it to a (kind of) retro-SBC design that I'm doing.
<cr1901_modern>
I basically came to the conclusion that I'll have to accept that the SBC is going to be a financial loss :P
<sb0>
cr1901_modern, and your sales will suck because everyone will get a cheaper rpi instead
<cr1901_modern>
Yes, I'm very very well aware of that :'(
<cr1901_modern>
Not that I really intended to sell my design anyway- it was a thought experiment more than anything (though I'd happily sell to anyone who wanted one)
<whitequark>
there is about as many SBCs as there are 3D printers
<whitequark>
and most of them suck
<cr1901_modern>
My SBC has limited appeal- it's slow, it uses a (modern implementation) of an old arch. But it's what I wanted to do lol. World has enough ARM boards.
<cr1901_modern>
It's one of those "Why? Because I can" things
<whitequark>
you seem to have very little understanding of the complexity that goes into manufacturing more than five of anything
<cr1901_modern>
Seem? I haven't made a PCB yet that didn't have mistakes that I had to fix myself.
<cr1901_modern>
I didn't actually *intend* to mass produce a PCB. I just wanted to do the number crunching and see how low I could get the unit price if I ordered all parts in bulk, ignoring actually having to store the inventory and other fun things I'm sure I'm missing
Gurty has quit [Quit: Coupure de courant]
<cr1901_modern>
But out of morbid curiosity, what was your hint?
<whitequark>
"I'd happily sell to anyone who wanted one"
<cr1901_modern>
Yea, all 5 of them :P
<cr1901_modern>
(I wasn't kidding about limited appeal)
<cr1901_modern>
Okay, I see what you're saying
<cr1901_modern>
by "sell", I mean "I don't really make a profit b/c I have to make the thing, test it, and then package it, and that takes time"
<whitequark>
no, making a profit requires taking all that to an entirely new level. i was talking merely about actually shipping
<cr1901_modern>
If I wanted to do more than 5, I suspect I would have to invest in some hardware that helps speed up the process/do things in parallel, correct? Like the goodies you have.
<cr1901_modern>
The lower the unit cost, the higher the startup cost :/
<ysionneau>
Is this Vivado crash known by someone? (building artiq_kc705) http://pastebin.com/T7H2tTiX , I'm using the vivado 2014.2 from rjo minimalistic Vivado install + a few .lib files that were missing (and which provoked the "flex error")
<sb0>
no, never seen that
<ysionneau>
Ok, maybe it comes from the "minimalistic install"
aeris has quit [Read error: Connection reset by peer]
aeris has joined #m-labs
mumptai has joined #m-labs
cr1901_modern has quit [*.net *.split]
kristian1aul has joined #m-labs
mumptai has quit [Ping timeout: 244 seconds]
kristianpaul has quit [Ping timeout: 244 seconds]
cr1901_modern has joined #m-labs
mumptai has joined #m-labs
_florent_ has quit [Quit: Leaving]
aeris has quit [Ping timeout: 246 seconds]
aeris has joined #m-labs
Zou has joined #m-labs
Guest37650 has quit [Ping timeout: 246 seconds]
Zou has quit [Quit: Coupure de courant]
antgreen has quit [Ping timeout: 240 seconds]
mumptai has quit [Remote host closed the connection]
Gurty has joined #m-labs
Gurty has joined #m-labs
cr1901_modern has left #m-labs [#m-labs]
cr1901_modern has joined #m-labs
nicksydney has joined #m-labs
<cr1901_modern>
Anyone who remembers: A verilog inout is an element where the output has an output enable attached to it, but input does NOT have an input enable?
<rjo>
i think you can only have an inout on an actual external (pin) signal. you would never connect two modules with an inout. also, all signals are always "readable". so there is no "input enable". dows that answer the question?
<cr1901_modern>
yea, it does... just trying to connect a CSR reg bank to the data inout of a design
<rjo>
afaict in fpgas internal signals alwyas have exactly one driver.
<rjo>
TSTriple?
<cr1901_modern>
yes, I've done that, but the actual reg file isn't showing up
<cr1901_modern>
I think I know why... but I wonder why I can't do it this way
<rjo>
"reg file"? the csr bank?
<rjo>
you need something that collects the CSRs and claims ownership and connects them to the bank (AutoCSR + CSRBankArray IIRC).
<cr1901_modern>
yes, the csr bank. I'll mess around with it a bit more and see what I'm doing wrong