<strlst>
hello there, is this an active community for riscv related discussion?
<ikke>
yes
<mps>
topic says ' RISC-V instruction set architecture' so I think this channel is about ISA
<strlst>
I was wondering which outlet would be the best place to start interacting with the community, it would be nice to discuss riscv related topics; I'm currently beginning to work on my bachelor thesis, which is about trying to extend a riscv implementation out of a lab course to support the basic operation of an operating system, I was wondering if anyone has a more clear picture than me and could give me some
<strlst>
guidance
<strlst>
oh wow, the message got too long, well
<strlst>
there are different aspects I'm trying to look at, one question would be which extensions are actually necessary to run an operating system
<strlst>
another would be whether privileged instructions are necessary (for which operating systems) and whether something like linux would be harder to bring to life compared to something like an RTOS
<strlst>
does anyone have pointers to study this in more detail? I've been collecting various bits and pieces and also looking at what sifive does, but it's not very systematic as of yet
<strlst>
really, the inspiration here would be to actually find out which extensions are necessary, extend the lab exercise riscv implementation accordingly and offer future students of the lab course the possibility to run a basic operating system on their very own designs
littlebobeep has joined #riscv
<strlst>
(maybe this is already beyond the scope of this irc room, if so, I'll look elsewhere (and sorry for my disturbing the peace here))
littlebo1eep has quit [Ping timeout: 240 seconds]
<strlst>
for one thing, I'm currently trying to find out what boot flows there exist and how they work, so that I can start thinking about how a boot flow would have to look like (and then investigate which extensions are actually needed), I just feel a bit insecure because there's so many moving parts I don't fully understand and so I keep wondering whether this is the path to an acceptable solution
jjido has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
pecastro has joined #riscv
littlebobeep has quit [Ping timeout: 240 seconds]
haise01 has joined #riscv
littlebobeep has joined #riscv
q66 has joined #riscv
littlebo1eep has joined #riscv
BootLayer has joined #riscv
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #riscv
littlebo1eep has quit [Ping timeout: 240 seconds]
BootLayer has quit [Quit: Leaving]
q66 has quit [Quit: No Ping reply in 180 seconds.]
littlebobeep has quit [Ping timeout: 240 seconds]
q66 has joined #riscv
littlebobeep has joined #riscv
seninha has joined #riscv
seninha has quit [Remote host closed the connection]
seninha has joined #riscv
morealaz has joined #riscv
yeirr has quit [Ping timeout: 240 seconds]
littlebo1eep has joined #riscv
yeirr has joined #riscv
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #riscv
littlebo1eep has quit [Ping timeout: 240 seconds]
BootLayer has joined #riscv
morealaz has quit [Quit: morealaz]
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #riscv
<muurkha>
strlst: you don't need any RISC-V extensions to run something like an RTOS; the base unprivileged integer instruction set is enough. for preemption you also need some kind of timer interrupt, and timers are not part of the instruction set (in general, not just on RISC-V)
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #riscv
<muurkha>
but for a protected-memory operating system like Linux, where one process can't overwrite the memory of another and cause it to crash, you need the privileged instructions and in particular the page table stuff
<muurkha>
and for SMP operating systems, where you have more than one processor accessing the same memory, you need either the A extension (and maybe Zifencei) or something functionally equivalent to it. like, it might happen that a simple RISC-V SMP implementation, especially without caches, has memory ordering properties that the architecture doesn't guarantee; and often it's easy enough to get SMP working on top
<muurkha>
of such ordering properties. but using the A extension is probably a better idea
<muurkha>
booting and devicetree and device initialization are, for better or worse, outside the scope of the ISA per se. if you're putting together a teaching machine out of raw gates you can make those as simple as you want
<muurkha>
(hopefully if I've said anything particularly boneheaded above someone like palmer or jrtc27 will be kind enough to correct me)
<muurkha>
does that help?
peepsalot has quit [Quit: Connection reset by peep]
peepsalot has joined #riscv
indy has quit [Read error: Connection reset by peer]
indy has joined #riscv
<muurkha>
oh I guess if you're going to handle interrupts and ECALL and the like in the standard RISC-V way you need Zicsr too
<muurkha>
as with the A extension, you can also do them in some other incompatible way
indy has quit [Excess Flood]
indy has joined #riscv
<strlst>
muurkha: sorry I was gone for a while, thank you for your response, I really appreciate it
indy has quit [Ping timeout: 240 seconds]
<muurkha>
hopefully it doesn't mislead you too badly. I haven't actually implemented either an OS or a CPU so I might be overlooking crucial elements!
<strlst>
at the very least what you are saying makes sense, but I would say only if there is actual exception handling implemented, so that unimplemented instructions are still handled correctly using trap handlers to emulate their functionality (or if the entire software stack is recompiled for the base integer instruction set)
littlebobeep has quit [Ping timeout: 240 seconds]
<strlst>
at the very least, the implementation would be kept simple, so no issues stemming from the execution of multiple processors can arise
indy has joined #riscv
<strlst>
you've also said booting, devicetree and device initialization are outside the scope, I suppose that's true, but just to make sure: they would still be relevant if I wanted to make something run on live hardware, right?
indy has quit [Ping timeout: 246 seconds]
<strlst>
previously I thought exceptions, interrupts and trap handlers were part of some kind of exception extension, but that may habe been a gross misunderstanding, I guess I should look up how exceptions are actually specified or what they need in the first place
<strlst>
regarding our comment about the page table stuff, it's interesting, I think it was in the computer architecture (a quantitative approach) book where it was mentioned that virtual memory relies on exception handling to handle page faults correctly
<mps>
exceptions are mostly cpu generated by wrong opcode, wrong address and other violations
<mps>
interrupts are usually hardware (peripheral) generated
ivii has quit [Ping timeout: 272 seconds]
<strlst>
yeah, I think the specification says that exceptions are internal and interrupts external interruptions of the control flow
<mps>
I didn't yet read all riscv documents and not sure about terminology used
<strlst>
I see
<mps>
but above is in general about cpu/computers
<strlst>
am I correct in thinking that for exception handling I would need CSRs as well as the Zicsr extension?
<muurkha>
normally yeah
<muurkha>
ECALL and SCALL are handled in the same way as interrupts and exceptions, but if you don't have a privileged mode you could call your OS with ordinary call instructions
<mps>
some 'people' even call syscalls interrupts but imo this is wrong
<strlst>
okay, good to know, thank you
<muurkha>
what interrupts are crucial for is preemption
<strlst>
you mean preemption of processes by other processes?
<muurkha>
right
<mps>
muurkha: yes, syscalls could have defined 'vector address' like normal interrupts
<mps>
so they are similar how they work, but fundamentally they are different things
<muurkha>
preemption is where one process is processing along, minding its own business, maybe solving a large system of linear equations or something
<muurkha>
and then suddenly the CPU is running something else
<strlst>
I suppose I need to look up how preemption (and possibly other syscalls) actually work in linux if I wanted to support linux on the basic riscv processor implementation
<muurkha>
this is a very important thing to be able to do for two reasons:
<strlst>
yeah, I've learned a little about preemption, only theoretical stuff though
<strlst>
like different scheduling strategies
<strlst>
for instance, it's important to prevent starvation and keep applications response
<strlst>
responsive*
<muurkha>
1. your process may be actually in an infinite loop and you need to stop it so you can debug it. or more generally you want other background processing to happen even if one of your processes is buggy
<mps>
strlst: there are two basic kind of preemptions, voluntary when process give other processes chance to run, in forced where something (usually timer) stop execution of process and give chances to other processes
<muurkha>
2. I/O generally has some kind of deadline, and unless you put a call in the middle of your linear equation solving routine to check for, say, serial port input, you are likely to miss those deadlines
<strlst>
mps: like for instance waiting for blocking I/O and on the other hand being paused by the OS?
<muurkha>
if your serial port is running at 1 Mbps and it is equipped with a 16-byte FIFO and no DMA, you have 128 μs to shovel out the FIFO once it starts receiving characters. or 160 μs if you have a start and stop bit
<muurkha>
if you don't respond to the serial port interrupt within that time, you will lose data
<strlst>
muurkha: yeah, that makes sense, looks like preemption is actually very important
<mps>
strlst: ther are different strategies to implement this, but basically you are right
<muurkha>
there's also a #3 which is that interrupts are more efficient than just polling every single I/O device every 100 μs or whatever
<muurkha>
but that's not as important as #1 and #2
<muurkha>
and yeah you do need to handle booting and device initialization in one way or another to boot on actual hardware but that can be very simple indeed
strlst_ has joined #riscv
<muurkha>
for example, your processor can start execution after reset at some particular address, like 0xAaaaAaa0, and you can burn your OS code into its flash with the initialization entry point at that address
<muurkha>
generally we don't say that yielding the CPU when you make a system call is "preemption"; it's a "context switch" but not a preemptive one
<muurkha>
normally "preemption" is reserved for what mps called "forced preemption"
<mps>
yes, initialization and boot are usually straightforward (easy) but later work is where complications come
<strlst_>
muurkha: that's very reassuring to hear, that it can be simple, I would very much love being able to actually set up or implement something so that students can run useful code on their basic implementations
<muurkha>
initialization and boot are *not* usually straightforward and easy, but if you're designing the hardware yourself you can make them straightfroward
<strlst_>
oh yeah, I've heard about context switches, that's good to keep in mind
<mps>
muurkha: my experience is that boot/init is not much complicated
strlst has quit [Ping timeout: 246 seconds]
<mps>
though more than 30 years passed when I last time designed some kind of OS
<strlst_>
oh, my new session isn't authenticated somehow (?)
<muurkha>
well, it depends on your hardware, but initialization and boot are usually quagmires of backward compatibility hacks during which you often have to detect what hardware is present in such a way that you don't run the risk of setting other possible hardware on fire or hanging it
<strlst_>
that's been my perception as well, but only after a very cursory look
<muurkha>
and for example if your RAM is external you may need to run the initial Memory Reference Code or whatever without using any RAM until you've succeeded in turning the RAM on
<strlst_>
I suppose for a limited context with more freedom in the sense of freedom to choose whatever it would be easier
<mps>
muurkha: well, right, it is not so easy as I told but comparing to other kernel subsystems it is simoler ime
<muurkha>
mps: the thing is that other kernel subsystems can be made as simple as you like. filesystem? store into an array. context switch? that's setjmp/longjmp. but initialization has complexity imposed on you by your hardware, and it's a pain to debug because until you've initialized some I/O device it's hard to get feedback on what's going wrong
<muurkha>
strlst_: your nick is strlst_ instead of strlst and so you can't authenticate until you switch over
strlst_ is now known as strlst
<muurkha>
btw you might have missed this part of the chat:
<mps>
muurkha: right, but usually we make os for somewhat known hardware
<strlst>
no worries: I've looked up the history to make sure I haven't :)
<muurkha>
14:16 < strlst> muurkha: yeah, that makes sense, looks like preemption is actually very important
<muurkha>
14:16 < mps> strlst: ther are different strategies to implement this, but basically you are right
<muurkha>
14:17 < muurkha> there's also a #3 which is that interrupts are more efficient than just polling every single I/O device every 100 μs or
<muurkha>
whatever
<muurkha>
14:18 < muurkha> but that's not as important as #1 and #2
<muurkha>
14:18 < muurkha> and yeah you do need to handle booting and device initialization in one way or another to boot on actual hardware but
<muurkha>
all praise be to whitequark, our generous logger
<strlst>
so can I maybe ask real quick, do you two think it's feasible to get some basic operating system running on an (terasic DE0) FPGA that implements an RV32I soft core?
littlebobeep has joined #riscv
<mps>
strlst: depends on you, but sure is possible
<muurkha>
yes, definitely
<strlst>
my supervisor told me if it turned out to be too much work, he would be fine if I at least tried to systematically categorize approaches and make it more theoretical of a work where I generally work out what can be done and how that would be done, but if I'm honest I want to see something useful run on that soft core, it doesn't sound impossible to me going by what I know by now
<muurkha>
for cooperative multitasking without memory protection all you need is setjmp/longjmp
<strlst>
okay, it's good to know that I'm not up against an impossible task
peepsalot has quit [Ping timeout: 255 seconds]
<muurkha>
(and some way to create a new stack, like the setcontext/makecontext/getcontext triple provide)
<muurkha>
for preemptive (non-cooperative) multitasking without memory protection, you additionally need a timer interrupt
<geertu>
strlst: As there was preemptive multitasking on plain 68000, RV32I should be sufficient.
<mps>
few weeks ago when I started to read riscv ISA from my back brain come idea to find my old forth for Z80 and rewrite it for riscv to be bare metal forth
<muurkha>
which means you need Zicsr or some substitute; RV32I doesn't include Zicsri
<muurkha>
mps: sounds like fun!
<muurkha>
*doesn't include Zicsr
<strlst>
if it was only Zicsr, that doesn't sound too bad to implement, I actually expected to need more
<mps>
muurkha: yes, fun but I'm not sure will I do that ever
<muurkha>
also remember that MS-DOS didn't have multitasking or memory protection at all, and Windows 3.1 had cooperative multitasking but no preemption or memory protection
<strlst>
mps: at least you won't have to look for ideas for when you are bored :)
<muurkha>
so you can go quite far for interactive computing without preemption or memory protection
<strlst>
geertu: thank you, I will look into it
<muurkha>
MS-DOS did have a timer interrupt and so it was feasible to do quite a bit of real-time stuff in the background without actual multitasking
<muurkha>
generally RTOSes do provide preemptive multitasking with priority scheduling
<mps>
(last two decades I'm userspace programmer only)
<strlst>
the problem with trying to find out how to do something is that only in hindsight is it obvious what has to be looked into; I'm generally open and grateful for directions and resources
<strlst>
aren't there RTOSes that use fixed schedules, without needing preemption (are there any in practice?)
<muurkha>
preemptive multitasking to be useful needs some kind of synchronization construct between threads; for that the A extension is useful but probably not necessary
<muurkha>
no, to impose a fixed schedule on user processes you need preemption
<strlst>
makes sense
<muurkha>
for memory protection at the hardware level you need the privileged ISA and Zicsr
<muurkha>
(or some simpler alternative, but the RISC-V privileged ISA is already pretty simple)
<muurkha>
there are various alternatives to the mainstream approach outlined above
<strlst>
does linux always need privileged instructions? I've seen mention of "m-mode linux", but I wonder what that actually means
<muurkha>
there's a thing called uclinux which is a version of linux without privileged instructions (or memory protection)
<strlst>
that's very curious, thanks for the pointer
<muurkha>
but you need them for fork()
<muurkha>
well. technically you could implement fork() (and also context switching) by copying all of memory to some storage medium, which I've been told is how Unix did it on the PDP-7
<muurkha>
but it's not really an apealing solution
<muurkha>
alternatives to multitasking by switching stacks: Adam Dunkels's "protothreads" is a super-low-memory implementation of a limited form of multithreading
<muurkha>
also things like Erlang implement multitasking at the level of a virtual machine or interpreter, but that's a lot more complicated than just switching stacks
<strlst>
yeah, that doesn't sound particularly good as a solution, offloading to memory can be very expensive
<muurkha>
and in, say, Scheme, call-with-current-continuation ("call/cc") gives you a form of multithreading that suggests not using stacks at all
<strlst>
erlang is very interesting, but isn't it "virtual" threads running in a runtime environment?
<muurkha>
right
<muurkha>
but all threads on a single-threaded processor are virtual
<strlst>
call/cc sounds a bit like a form of forking
<muurkha>
it's a lot more complicated than that, and simpler
<strlst>
yeah, true, threads on a single-threaded are always virtual, now that you mention it...
<strlst>
does call/cc work like a form of fork/join parallelism?
<muurkha>
no, it's much weirder than that
<muurkha>
but you can use it to implement fork/join parallelism
<strlst>
that sounds like it would be fun to look into
<muurkha>
it is, it's a total mind bomb
<muurkha>
the E programming language uses closures and "promises" instead of multithreading, which is a pretty interesting approach too. also within an interpreter
<muurkha>
it's an approach that has sort of gone mainstream (incorporated into Python, JS, and Rust) in the form of "async/await"
<strlst>
it's good that there are so many models
<strlst>
yeah, a friend of mine showed me the "suspend" model for async used by zig
<muurkha>
oh yeah, I didn't know Zig had adopted async too
<muurkha>
alternatives to memory protection with page tables and the privileged instruction set: well, Java protects threads from one another by running them in a virtual machine that bounds-checks all their memory accesses; Python does something similar
<strlst>
but I imagine the JVM won't run as an operating system itself (or will it?)
<muurkha>
it will!
<muurkha>
that was its original purpose, and JavaME was the major use of Java for many years
<strlst>
oh wow, that's interesting
<muurkha>
Smalltalk-80 is sort of the origin of this approach, but there were a bunch of timesharing BASIC implementations back in the 01960s
<strlst>
I never looked into java ME, I was always wondering how a JVM would run on an embedded platform
<muurkha>
and a lot of microcontrollers have something called an "MPU", which AFAIK is not contemplated in the RISC-V manuals: it doesn't remap memory pages (so you don't get fork()) but you do have different privilege levels that can read and write different parts of memory
<muurkha>
the idea is that when you're running the kernel ("supervisor") you unprotect the memory pages where the kernel data is stored, and when you return from a system call you protect them again, as well as any pages belonging to other processes
<muurkha>
this potentially doesn't require a whole tree of page table entries, just a couple of bitvectors
<muurkha>
but the OG memory protection approach, used in Unix on the PDP-11, is base and break registers
<strlst>
the advanced computer architecture book (by Patterson and Hennessy) talked about how the intel pentium does memory protection, but it was so convoluted I couldn't follow it
<strlst>
I guess modern memory protection is page based
yeirr has quit [Ping timeout: 246 seconds]
<strlst>
yeah it would make sense for me that different pages would be accessible only for code running at a certain privilege mode
<strlst>
that there are so many different ways to do things makes it a bit difficult to see the trees inside the forest
yeirr has joined #riscv
<muurkha>
well, the standard mainstream approach is to have a page table tree that controls an MMU
morealaz has joined #riscv
<strlst>
muurkha: where did you learn about these things? did you soak them up over time or do you do related work? just wondering, since I'm very interested in having a good understanding about computers
<muurkha>
the RISC-V privileged ISA spec explains how that works in standard RISC-V, and it's relatively straightforward
<muurkha>
and it's pretty efficient and very flexible
<muurkha>
oh, I never learned about these things, I'm just a muurkha
<muurkha>
I have had computer-oriented jobs since 01996 though
<strlst>
okay, I will definitely look into the privileged ISA in more detail, that's good to know
<strlst>
I see, born a prodigy huh :)
<strlst>
I wasn't aware, but the MMU is the name for the additional hardware that's needed so support a memory system like virtual memory (is that right?)
<muurkha>
I mean I did have some special abilities but objectively speaking my progress was really slow
bauruine has quit [Ping timeout: 244 seconds]
<muurkha>
so I guess my special prodigy abilities didn't really help me that much and may have hurt
sobkas has joined #riscv
<strlst>
oh wow, that's curious, makes me feel a little better about doing everything one step at a time
<strlst>
thank you for sharing
<strlst>
(it's not to be taken for granted that someone has documented their learning process)
littlebobeep has quit [Ping timeout: 240 seconds]
morealaz has quit [Quit: morealaz]
<muurkha>
speculating, I'd say I got really attached to my self-image as "smart" and "good at computers" as a kid, which had good effects (on my learning) and also bad ones
<muurkha>
the good effect was that I spent a lot of time programming and reading about computers and their history and stuff
<strlst>
I suppose in the end it turned out fine, looks like
<muurkha>
the bad effect was that what I was programming was not very innovative; I had one year of programming experience repeated ten times
<muurkha>
and I avoided people who knew more than I did because they made me feel insecure
<strlst>
that sounds very human to me, even if it isn't the best way to learn
<muurkha>
just like programming things at the edge of my abilities, which is what I would have needed to do
<strlst>
I wonder if there is someone who doesn't struggle with some kind of impostor syndrome
<muurkha>
well, when I think about the times when I have learned the fastest, they were times when I wasn't trying to measure my performance against some kind of standard
<muurkha>
so not only didn't I have impostor syndrome ("I'm not as good as they think I am/I'm not smart enough to do this") I also didn't have whatever you'd call the opposite ("I am the greatest programmer in the world, all others are inferior to me")
<muurkha>
at those times
<strlst>
oh I see, like reading a book in a different language and being so interested that one forgets one is reading in a different language at all
<mps>
strlst: I don't suffer form impostor sindrome, except when I do ;)
littlebobeep has joined #riscv
<mps>
s/form/from/
<strlst>
mps: as long as it's a small enough fraction of the time
<muurkha>
quite aside from their objective truth value, such self-assessment questions are not the same thing as whatever you're trying to learn. every second you spend thinking about whether you're too dumb to hack it is a second you're not spending on hacking it
<muurkha>
worse, every ten-minute interval in which an intrusive thought arises that you're too dumb to hack it is a ten-minute interval in which you flow is broken
<strlst>
I guess I've largely stopped trying to compare myself too, but sometimes I feel like I'm being disingenious and like I could do more if only I work more towards it
<mps>
yeah, 'just do it'
<strlst>
that makes a lot of sense yeah
jacklsw has joined #riscv
<muurkha>
it's like someone coming in to ask you a question about something unrelated, it disrupts your focus, and focus is what you need to learn a new skill
<strlst>
I've read somewhere: don't let perfect be the enemy of good
<mps>
my advice (and I don't like to give advises around) would be, learn and try
<muurkha>
and it doesn't help if the intrusive thought is "Bob over there would have been too dumb to do what I just did" instead of "I'm too dumb to hack it"
<strlst>
that's so true, focus is very precious
<strlst>
mps: I'll take it to heart
<muurkha>
anyway, so when I've been able to let go of my ego, which was not very often when I was 8, I've been able to make much faster progress
<strlst>
thank you guys, your words have been very encouraging so far
<strlst>
at the very least I feel like the goal is not as distant anymore
<muurkha>
yeah, there's a lot to learn, but it's accessible
peepsalot has joined #riscv
<strlst>
it's kind of the point of riscv I guess :)
<mps>
strlst: ime, when I started low level hardware programming I didn't had any idea what I can do, but I did and that is which satisfies me
<muurkha>
RISC-V helps a lot!
<mps>
and I don't have any official computer education
<strlst>
mps: in the end, how did you actually get into it?
<strlst>
oh, really? that's interesting
<muurkha>
yeah, I have a little but not much
<strlst>
I gues smotivation trumps all
<strlst>
s/gues smotivation/guess motivation
<muurkha>
motivation is important, but you can self-sabotage in a variety of ways even if you have motivation
<[exa]>
^ +1
<mps>
strlst: yes, motivation is most important, imo
<muurkha>
it's also important to have competent mentors guiding you
<mps>
also one should be able to judge self honestly
<muurkha>
which it sounds like you do
<mps>
and persistence ofc
<strlst>
yeah, my supervisor is more of a university assistant, but he is very young, knowledgeable and forgiving
<muurkha>
interesting, I was saying judging yourself at all is counterproductive, whether honestly or not; it sounds like you disagree?
<mps>
"don't give up easy"
morealaz has joined #riscv
<strlst>
I guess I should be more open towards asking him questions instead of trying to do everything alone
<[exa]>
strlst: btw is that implementation you're extending public somewhere? (/me interested in small-ish hackable projects)
<muurkha>
"forgiving" is not a word that should be applied to not knowing things; ignorance is not a sin that needs to be forgiven
<mps>
muurkha: not judging as term usually used, but more like some kind of inner introspection
<muurkha>
maybe you're stealing his office supplies or something and that's what he's forgiving though
<[exa]>
strlst: also, by all means, DO ASK your supervisor in any case of doubt, students who don't ask basically create a problem for themselves :]
<strlst>
[exa]: yes, my implementation is hosted on notabug.org, but notabug.org is actually having an outage right now
<strlst>
I'm not entirely sure whether it's even fully correct (it is tested though), but it did actually run on an FPGA and send things over UART
<muurkha>
nice!
<[exa]>
"practically correct"
<muurkha>
I still haven't gotten anything running on this FPGA board I got last month
<strlst>
oh so coreboot does riscv now, that's interesting
<muurkha>
it'd be nice from my point of view if the FPGA board had an ADC and a DAC on it
<strlst>
I think I only every witnessed boot flows that use opensbi and u-boot
<strlst>
muurkha: I'm currently playing around with a basys 3 and it has an on-chip 12bit ADC
<muurkha>
just from the point of view that high-data-rate parallel data paths to off-board ADCs or DACs are likely to suffer signal integrity issues
<strlst>
oh, apparently it's a core withing the artix-7 itself
<muurkha>
how fast is the ADC?
<strlst>
s/withing/within/
<strlst>
1 MSPS
<strlst>
is what it says, I wonder what unit that is, I haven't encountered it yet
<muurkha>
oh, at that speed you could put it on a different board without much proble
<muurkha>
m
<muurkha>
megasamples per second
<strlst>
ohh, I see
<muurkha>
there are some noise problems with putting the ADC on literally the same chip though
<strlst>
I guess it's useful/convenient for development to have one on-chip thoughh
<muurkha>
digital computation slams lines from Vcc to ground, or vice versa, as fast and hard as possible, and that generates a lot of noise
<muurkha>
yeah, for sure
<[exa]>
strlst: oh nice, thanks
<muurkha>
but 1 Msps is too slow for, for example, decoding DVB-T on the FPGA
littlebobeep has quit [Ping timeout: 240 seconds]
<strlst>
interesting
<strlst>
well, thankfully there are pins to connect an external ADC, although I wonder how well that would work
<muurkha>
the RISC-V softcores that have most attracted my attention are https://github.com/T-head-Semi/openc906 (supposedly super fast, used in the Allwinner D1)
<strlst>
oh yeah, t-head was a subdivision of alibaba wasn't it
<muurkha>
there are times when the 32× slowdown of a bit-serial CPU doesn't really matter. like, if you're doing your real computation in the rest of the FPGA, and you just need some way to script state transitions
<muurkha>
or you're doing real-time control
<strlst>
is the slowdown worth the transistor savings? it feels like riscv is already small
<muurkha>
though to be fair probably you could do a lot better by using a wider range of 7400-series chips
<muurkha>
still, in the context of trying to wire up thousands of chips into a CPU, an order-of-magnitude complexity reduction would be very welcome
<strlst>
the reverse engineering efforts of some never cease to amaze me
<strlst>
it's incredible actually
<strlst>
I think I've read that the FPGA chip the basys 3 board uses can be partly used (because it's partly reverse engineered)
<muurkha>
it's an ongoing struggle
<strlst>
if everything was open in the first place it wouldn't be as hard, although I guess some people swear by learning by reverse engineering
vagrantc has joined #riscv
<muurkha>
well, it used to be
<strlst>
oh, really
<muurkha>
up to about 01990 it was routine for hardware vendors to publish full details of how to program their hardware
littlebobeep has quit [Ping timeout: 240 seconds]
<strlst>
it's kind of sad everything has become so closed
<muurkha>
not everythign has become so closed
<strlst>
well, some things
<muurkha>
it was also routine for operating systems and compilers to be legally encumbered at the time
<muurkha>
and there was nothing like Wikipedia, BitTorrent, Library Genesis, Sci-Hub, or the Internet Archive
<strlst>
okay, fair, that's a balancing force for sure
<muurkha>
there were no Creative Commons licenses, and the only open-access scientific literature was US government publications
<strlst>
the wonders of the internet
<muurkha>
software generally was not patentable, and it was unusual to sign an NDA when you took a job
<muurkha>
and the sheer number of patents was a trickle compared to today's flood
<muurkha>
also, you could get on an airplane without an ID
<muurkha>
being asked for your "papers, please" to travel was relegated to World War II movies and day-to-day life in dictatorships, whereas now it's universal for air travel
<strlst>
and yet people are ridiculed for bringing up how much our world operates on "papers, please" nowadays
<muurkha>
they were then, too, in the dictatorships
<muurkha>
the US and Western Europe basically didn't have an official censorship apparatus like the one that's being deployed to various degrees against Russia Today and other anti-US propaganda outlets
<strlst>
well, that makes sense, although it's sad
<muurkha>
and against copyright infringers
<strlst>
copyright enforcement does seem like a big stepping stone hindering progress, but that's just my humble opinion
<muurkha>
there was no DRM preventing you from fixing your computer or your TV or your tractor, which are all common today
<muurkha>
so I don't think it's a simple story of things becoming more open or more closed
<muurkha>
yeah, I agree
<strlst>
yeah, you're absolutely right, they are just different
<muurkha>
also though the idea of progress itself is a lot less popular today than it was then
<strlst>
the tractor thing is very sad in my view, who are we to stop farmers from doing their job if they're able to fix a problem themselves? it's actually people securing our food supply...
<strlst>
I don't think progress itself is less popular, more like progress in a useful sense is less popular, the various movements towards enforcement of certain restrictions seem like progress to those who want those enforcements
<muurkha>
well, I mean there's a pretty strong social movement that believes progress is fake. they think that our comfortable lives today are purely because we're stealing from people in poor countries or from future generations
<muurkha>
this is reinforced by the fact that we are in fact stealing from people in poor countries and future generations to make our lives more comfortable
<muurkha>
but there's this whole "degrowth" ideology. sometimes it conflates economic productivity with fossil fuel use and sometimes it gestures at environmental devastation
<strlst>
oh well, civilization is so complicated
<strlst>
I guess the complexity in computers is a lot more contained than these social forces
littlebobeep has joined #riscv
<strlst>
ideologies can be so limiting, people become blind because they're preprogrammed to think something
<muurkha>
and now that a generation and a half has gone by since the collapse of actual socialism, so that many people don't know what it was like, socialism has become a popular ideology again
<muurkha>
Marx of course believed very strongly in progress, but many current socialists do not
<muurkha>
to me, living in the world of abundance created by open-source software and hardware, their zero-sum mentality is totally ridiculous
<strlst>
at this point I believe there are too many misguided approaches, it would probably be best to keep centralized power contained as small as possible
<muurkha>
heh, but currently the trend is the opposite
<strlst>
it's one of the cornerstones of economics that there is scarcity, but it's just not the correct model to view different things
aerkiaga has joined #riscv
<muurkha>
you can still have non-zero-sum transactions in scarce goods
<strlst>
for example, as people we all (I would think) need affection, a smile is free, it doesn't make sense to use a model that assumes scarcity
<muurkha>
indeed
<strlst>
yeah, the trend is opposite, for me that is pretty worrying
<muurkha>
my labor is scarce, and so is steak. but if I sell my labor to a client, who pays me scarce money that I then give to the butcher for a steak, all three of us are better off
<muurkha>
(probably, usually, but not necessarily. and of course the cow isn't better off)
<strlst>
not a world for cows it looks like..
<muurkha>
so, go forth and hack! :)
<strlst>
thanks, thanks, I will :)
<muurkha>
and save the papers you need from sci-hub, assuming that's legal in your country. after this war is over it's likely that there will be no sci-hub or libgen; maybe they'll be replaced by services only accessible within China
<strlst>
I've been hoarding a lot of books from libgen already, but I should do that for papers too probably
<muurkha>
there are torrents btw
<strlst>
true, I've seen the mega torrents, I've been meaning to contribute by seeding them, but I haven't expanded my storage as of yet
<strlst>
they're quite big
littlebobeep has quit [Ping timeout: 240 seconds]
<dh`>
holy scroll batman
<muurkha>
sorry dh`
<muurkha>
what have you been up to?
jjido has joined #riscv
littlebobeep has joined #riscv
<muurkha>
my STM system is still vaporware, but I never did find a way to preserve lock-freeness with strict priority scheduling and direct pointer access to transactional mutable data without copying it on read accesses, so I'm switching to a plan to make transactional mutable data accessed through an extra level of indirection
<muurkha>
I guess I should finish reading Fraser's dissertation before I commit to that though
indy has joined #riscv
<muurkha>
basically the case that was stymieing me is where you have multiple transactions of the same priority that enter a deadly embrace: each has read a block that the next one in the cycle is trying to write to
<muurkha>
the simple solution to this is to let them all proceed, but when one commits, abort the one that had read the thing written by the committed transaction; but I was pursuing an approach where opening a block for reading wouldn't copy it (and thus relocate it), while writing of course necessarily does make a copy. but because I wanted a transaction to be able to write to a block it had previously opened for
<muurkha>
reading, that meant that writing couldn't relocate the block *either*, because that would invalidate whatever pointers derived from the read operation
<muurkha>
I couldn't come up with a solution to the deadly embrace problem that preserved lock-freeness. you can kill one of the transactions in the cycle, but then if you just let it restart immediately it can produce livelock, and if you wait for one of the other transactions in the cycle to commit, then it might happen that they're all stuck in infinite loops
<muurkha>
so either way you lose the lock-free progress property
littlebobeep has quit [Ping timeout: 240 seconds]
<muurkha>
so at this point my thought is that every access to a mutable transactional variable has to go through an extra level of indirection so that the open-for-writing operation can redirect the pointer used for reads to point to the newly allocated shadow block
<muurkha>
what do you think?
littlebobeep has joined #riscv
<dh`>
muurkha: no need to be sorry, was just surprising given that this channel's been pretty dead in recent weeks
<dh`>
as for the question: I *think* that was what I was warning you about last time but maybe not
<dh`>
I don't remember exactly
<ikke>
dh`: Probably helps that a lot of new users received rv64 hardware recently
<dh`>
I also need to reboot, brb
dh` has quit [Quit: brb]
aerkiaga has quit [Remote host closed the connection]
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #riscv
`subline has joined #riscv
jacklsw has quit [Read error: Connection reset by peer]
littlebobeep has quit [Ping timeout: 240 seconds]
KombuchaKip has joined #riscv
bgamari_ has joined #riscv
bgamari has quit [Ping timeout: 252 seconds]
littlebobeep has joined #riscv
jjido has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
littlebobeep has quit [Ping timeout: 240 seconds]
yeirr has quit [Remote host closed the connection]
littlebobeep has joined #riscv
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #riscv
BootLayer has quit [Quit: Leaving]
littlebobeep has quit [Ping timeout: 240 seconds]
seninha has quit [Quit: Leaving]
conchuod has quit [Quit: Lost terminal]
littlebobeep has joined #riscv
conchuod has joined #riscv
zjason` has joined #riscv
zjason has quit [Ping timeout: 246 seconds]
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #riscv
<muurkha>
dh`: well, you were warning me more about the issues of moribund transactions looping forever or violating memory safety because they had seen things no mortal transaction must ever see. you might have brought up the risks of deadlock in this situation but I'm not sure
haise01 has quit [Ping timeout: 240 seconds]
eroux has quit [Ping timeout: 258 seconds]
eroux has joined #riscv
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #riscv
littlebobeep has quit [Ping timeout: 240 seconds]
jmdaemon has joined #riscv
littlebobeep has joined #riscv
<qwestion>
is anyone else than alibaba working on aosp or android for rv?
<qwestion>
like heavy porting and bugsquashing effort?
<conchuod>
palmer: do you want PRs from kernel.org, or do you only care about the properly signed tag?
<palmer>
having a PGP key in the kernel.org web of trust would be my only hard requirement, but IIUC that's also the only requirement for a kernel.org account and generally it's prefered to put your tree there
<palmer>
if there's some issue with that I'm happy to talk, though
<conchuod>
Nah, no issue that I'm aware of palmer - I got the keys sorted today, was just asking :)
<palmer>
cool
<palmer>
the kernel.org folks are generally pretty fast about setting up accounts, so hopefully it all just works out in time
<palmer>
I don't really plan on having any special requirements for PRs, but I was planning on sending out an email after this merge window just to make sure folks were on the same page
<palmer>
Kostandin did recently ask us all to be extra-strict about following all the security stuff (ie, PGP signing and what not) because of Russia, so I want to at least write down what I'm planning on doing (though it's pretty much just kernel.org WOT)
<conchuod>
In time is 9 weeks, so I am not too worried :)
<palmer>
and then just standard stuff like acks from other subsystems, time for reviews, and being consistent so folks don't get confused
<palmer>
yes, right, we should probably also re-open the discussion about fixes/for-next as IDK what's actually the right way to go there
<palmer>
it kind of doesn't matter if I'm just taking patches, but if I'm taking PRs then it's much harder to change around base branches and such
<palmer>
so might as well get settled on something, at least for a year or so at a time ;)
<conchuod>
Ye, tbh a large part of why I want to do it is to take some of the pressure off of you, having to keep an eye on the sequencing etc
<palmer>
yep. that's the idea
<conchuod>
So I am down to do whatever works for you with that stuff, not fussy *at all*
<palmer>
yep, we talk about maybe doing this every year or so -- it's just that nobody ever says "yes, I want to send PRs" so we never really talk about what the rules should be
jjido has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<palmer>
every time I do a cross-tree merge it's a one-off thing that requires a lot of coordination, so if I'm regularly getting PRs then having some sort of plan will sort that out
<palmer>
(well, not for the cross-tree PRs, no way to fix that one)
<conchuod>
I guess I have motivation to actually do it b/c the number of items in dts/microchip "might" end up growing a bit & I don't want to be an undue burden
dh` has joined #riscv
<dh`>
whee
<dh`>
"brb" turned into a multihour kernel debugging run
aerkiaga has joined #riscv
<conchuod>
I guess w.r.t. rules, following what arnd & co do is prob a good start palmer?
<palmer>
ya, and that's how I generally try to do things (I guess I was more based on Will for a bit, but whatever) -- the problem is that everyone has subtly different ways of doing things, so it sort of just needs to be written down
<palmer>
at least if it's written down then I have to think through it, everything's kind of vague right now
<palmer>
but the hope is to avoid anything complex
<palmer>
right now it's sort of just "rc1, aside from that first merge window PR" and that might be good enough -- doubly so if I can actually get ahead of the merge window like I want to, so it's just one merge window PR and then fixes
<conchuod>
Ye, I would prob follow Nicolas' approach for arm: send a PR prior to the window opening & then fixes if they arise later on.
<palmer>
ya, that's always my goal
<palmer>
it just never works that way, there's too many patches
<palmer>
but if other folks are going to be involved it's probably worth being stricter, and having help will of course make it easier to do so
<conchuod>
I think I said it before, looking to try and help more beyond just my little corner.