riff-IRC has quit [Quit: PROTO-IRC v0.73a (C) 1988 NetSoft - Built on 11-13-1988 on AT&T System V]
riff-IRC has joined #riscv
riff-IRC has quit [Ping timeout: 256 seconds]
___nick___ has quit [Ping timeout: 272 seconds]
<muurkha>
sorear: not sure about Windows/286
<muurkha>
jrtc27: btw thanks for turning me on to CHERI. I've been reading the October 2020 tech report (UCAM-TR-951) and it's really inspirational
<muurkha>
sorear: I think Windows 3.0 and 3.1 only supported cooperative multitasking in order to simplify the whole concurrency thing. presumably also true of Windows 2. so probably no task switches on timer interrupts ever
<muurkha>
I was trying to teach a young friend of mine to program in the 90s and crashed into that. first infinite loop, time to reboot. I wasn't used to that since I was on Linux
<muurkha>
kind of discouraging for him I think
<muurkha>
I've been reading the CHERI TR, the wasm spec, and some stuff about the Burroughs 5000, in pursuit of doing a capability-safe system with optimistically-synchronized transactional memory on a microcontroller
<muurkha>
hopefully I can get a prototype up and running next week. it was especially encouraging to read about the Deimos system (from an earlier CHERI paper)
<muurkha>
basically my theory is that if all my concurrency is optimistically synchronized transactions with strict priority scheduling, nothing can ever block anything of lower priority (I don't have to worry about priority inversion or deadlock) and I can provide strong real-time guarantees for tasks that need them, like maybe video signal generation or something
<muurkha>
that's probably too vague to critique but I'm interested to hear what people have ot say
<muurkha>
*to
<muurkha>
wasm is very impressive, but the wasm spec is a little bit of a disappointment. early on it they define linear memories (for "transparent" types like integers and now v128) and tables (for nontransparent types like function refs) and it looks like they're going to define some sort of capability system where you can have some of your code not have access to some of your memory. but it turns out that's all
<muurkha>
sort of out of scope; a wasm module runs entirely in the context of a single linear memory, memory 0, so there's no way to manipulate capabilities to memory
<sorear>
wait, win3 didn't have anything like ctrl+break?
<muurkha>
that's all relegated to "the embedding system"
<muurkha>
maybe it did and I didn't know about it because I only used Linux
<sorear>
i never actually did win16 _programming_ and my memories of using it are super fuzzy
<muurkha>
ctrl+break is a pretty tough problem in a system without memory protection though
<sorear>
but both DOS and win9x could abort an infinitely-looping program without an OS reboot, assuming you don't have complications from lack of memory protection
seninha has quit [Quit: Leaving]
<muurkha>
like, sometimes the code is in a state where some invariant of some important data structure temporarily does not hold
<muurkha>
if you have preemptive multitasking you hold a lock during that time
<sorear>
~ abort, retry, fail ~
<muurkha>
but with cooperative multitasking you don't even hold a lock
<sorear>
you disable interrupts if you don't want the keyboard interrupt handler making a mess of things
<muurkha>
yeah, but that has two problems:
<muurkha>
1. it's not practical to do during the entire time that you're maybe mutating a data structure in win16
<muurkha>
2. now if your infinite loop happens with interrupts disabled you're still stuck
<muurkha>
so when the user aborts the program, how do you keep the corrupted data structure from crashing the system?
<sorear>
this is why you use a mac with a little pushbutton on the case connected to NMI#
<muurkha>
heh
<muurkha>
transactional memory seems to offer a clean way to deal with that whole mess
<muurkha>
also you could get ISA breakpoint boards with a breakpoint pushbutton too. I remember the ads in Dr. Dobb's
<sorear>
not really, hardware TM systems all have difficult-to-abstract limits that stop you from doing too much with data structures
<muurkha>
yeah, I'm definitely not talking about using hardware TM at all. among other things, the hardware I'm using doesn't have it
<muurkha>
probably when I actually get my hands dirty with transactional memory I'll be disappointed that it doesn't work as well as I hoped, but maybe I can still muddle through and get a workable system
<sorear>
optimistic concurrency with strict priority scheduling is a fun problem though, one i've considered
<muurkha>
what do you think about the approach?
<sorear>
pessimistic transactions are a reasonable hardware approach too, as long as you tag every transaction with a priority and abort the lower-priority one when a conflict happens
<muurkha>
what's the point of making your transactions pessimistic if they can get aborted anyway?
<muurkha>
does it make them easier to implement or something?
<muurkha>
I mean I guess it keeps them from getting aborted by a *lower*-priority transaction but in a single-tasking system with strict priority that's the behavior anyway, isn't it?
<muurkha>
maybe I sound like I think I know what I'm talking about but I don't, I've just read some papers. the only transactional systems I've ever used are, like, Postgres and SQLite
<muurkha>
(well, and most of Gray and Reuter. but that doesn't mean I know things, I don't, it just puts me at risk of thinking I do)
aerkiaga has joined #riscv
vagrantc has joined #riscv
lumberjack123 has quit [Remote host closed the connection]
lumberjack123 has joined #riscv
seninha has joined #riscv
vagrantc_ has joined #riscv
aurel32 has quit [Quit: leaving]
vagrantc has quit [Ping timeout: 260 seconds]
vagrantc_ is now known as vagrantc
aurel32 has joined #riscv
mahmutov has quit [Ping timeout: 260 seconds]
<sorear>
the point of pessimistic is that you have a *guarantee* the highest prio transaction will complete, because it pushes anything else out of the way
<sorear>
optimistic can't guarantee anything except the fastest, because it has no tracking of what the high prio transactions need
<sorear>
oh, single tasking
<sorear>
(but if it's single-tasking does that mean you're not running code and video signal generating at the same time?)
<muurkha>
well, I mean single processor
<muurkha>
I didn't mean single tasking
<muurkha>
and yes, you can't run application code and video-signal-generating code at the same time that way
<muurkha>
but you might be able to generate the video signal in an HBI interrupt and spew it out from an SPI peripheral, or (as in the Arduino TVout case and I guess the Sinclair ZX81) run the application code during the HBI or VBI
aerkiaga has quit [Remote host closed the connection]
<dh`>
transactional memory schemes all seem to be about trying to get the implementation to deduce the locking granularity you need, instead of working it out ahead of time
<dh`>
and consequently they all suck, because that's hard
mahmutov has joined #riscv
<muurkha>
dh`: my thought is that I can make most allocated persistent objects immutable and track reads and writes at per-object granularity
<muurkha>
so I can tweak the application software to have finer-grained "locking" (really false sharing and consequent transaction retries) by either breaking big objects into smaller objects and big transactions into smaller transactions
<muurkha>
or coarser-grained "locking", and consequently less overhead from copying the objects I'm writing to and logging the ones I'm reading from, by aggregating smaller objects into bigger objects (also helps with GC bandwidth and memory size) and smaller transactions into bigger transactions
<muurkha>
so to a significant extent the application software will be able to tweak the grain of the concurrency. but copying an object into your transaction log so you can write to it will still be a lot slower than taking a lock on it would have been