cfallin

Integrating regalloc with a more streaming approach is something we may want to look at in the future in our backend -- for now we have a more conventional regalloc that extracts live ranges and either does a backtracking allocation or linear scan. That happens between lowering, which is where empty crit-edge blocks are created, and final emission, where the branch peepholing happens and empty blocks disappear, so the blocks exist during regalloc if needed. Anyway, there's an interesting design-space here!

> I wish there was a nice wrapper dedicated to abstracting hardware support

The NetBSD kernel has the ability to be built as a library, letting various drivers be used in other ways -- it's called a "rump kernel" [0]. I've never played with it myself but my understanding is that this would be sufficient to provide drivers in one's own kernel, given enough plumbing and shims and such.

(With enough shims one could borrow drivers from any kernel -- see ndiswrapper to use Windows network-card drivers in Linux -- but the rump kernel scaffolding is supposed to make it easier.)

[0] https://www.netbsd.org/gallery/presentations/justin/2015_Asi...

+1 to Datalog -- it is fantastic for static analysis in particular! There are a bunch of papers from Yannis Smaragdakis' group on this; I built my thesis work on top of their system Doop [1] which is a whole-program points-to analysis written completely in Datalog.

In general it's very nice to be able to prototype queries/inference rules quickly and then tweak clause ordering, etc for performance later if needed.

[1] https://bitbucket.org/yanniss/doop/src/master/

Parent comment was correct at time of posting :-) This was a project from last Christmas that I was encouraged to post again; after inspiration from another thread here I added a new version that fits in a single sector.

Yup, PC hardware is actually not too bad as a bare-metal platform, and everyone should try writing an OS once! Sounds like a fun senior project.

... and now there's a true 512-byte version as well (removing the text and shifting some of the variables to other memory did it) -- `make floppy_1sector.img`. Anyway, thanks for the prompt/challenge!

Thanks for working that out -- I had looked into using a JS x86 emulator of some sort to put up a demo when I wrote this, but ran out of time last Christmas :-) Happy to hear it works with that emulator!

You're right, it started as an attempt to fit into 512 bytes but right now it's 4 sectors (2KB). Of course, on a modern hard drive with 4KB sectors, we might stretch our definitions a bit :-) (Though the BIOS still only loads 512 bytes in such a case)

(author here) that's good feedback; thanks! I tried to make this accessible by at least linking to Wikipedia or elsewhere when introducing new terms (SSA, etc.); that way a curious person could use this as a starting point. A lot of the concepts really aren't too bad once one sees examples!

Overprovisioning to ensure demand is met in the worst case also sounds like a very early-20th-century sort of design decision; that could be part of it!

Here's an interesting article about Spanish flu and radiators: https://www.bloomberg.com/news/articles/2014-02-17/our-indis...

"engineering manuals from the 1920s dictated that radiators and boilers be manufactured large enough for 'the coldest day of the year, with the wind blowing, and the windows open.'" (!)

This is apparently an artifact of the 1918 flu pandemic: building architects / heating engineers intended for windows to be kept open to ventilate spaces in the winter, and so steam heating systems were over-provisioned. A number of friends in old apartments in Pittsburgh had the same issue with building heat.

(Relatedly, I wonder what effect the current pandemic will have on the modern trend of well-sealed homes...)

Pittsburgh driving taxes one's navigation skills on a good day, to put it mildly. Lived in Squirrel Hill for 8 years and got used to it but it's probably the most local-knowledge-dependent driving I've seen in the US. The five-way at the bottom of Murray at Forward is fun too (you want to go straight, but WHICH straight?).

When I first moved to Pgh, the street map reminded me of this Mario Kart 64 level: https://mariokart.fandom.com/wiki/Yoshi_Valley

It was fun but happy to be back on the west coast now :-) Also, glad I've never had to drive in NYC -- that looks tense!

Reminds me of this onramp to I-376 in Pittsburgh, where you have a stop sign (!) at the bottom of the onramp (!!), which then dumps you into an exit-only lane with a few hundred feet to merge left (!!!):

https://www.google.com/maps/@40.4287854,-79.9328641,3a,75y,6...

I only took this ramp a handful of times before I learned to detour several miles to avoid it...

Ah, no, probably doesn't do parsing recovery. But `wasm-validate` from the same toolkit will at least tell you the offset at which your wasm file has an error (I just flipped some bits in a wasm file to test this), which may be helpful!

> reading the binary format ... it'd be nice to do more advanced debugging with a text format.

Do you know about `wasm2wat` (from the WebAssembly binary toolkit, "WABT")? It produces a 1-to-1 text representation of the bytecode and is meant to always roundtrip via `wat2wasm` back to the same bytecode.

Compact / succinct data structures and clever algorithms are still very important when data gets large enough -- consider e.g. a database running complex queries, where a good encoding makes the difference between staying in memory and going to disk. Basically the machines became larger but so have the problems to solve.

Soul of a New Machine is fantastic!

Also on computer architecture / story of developing a new processor, "The Pentium Chronicles" by Robert Colwell is a really interesting book on the story of the Pentium Pro, the first out-of-order CPU from Intel.

> What codec would you use for a camera that captures not RGB, but poetry of the soul?

I would love to read a collaborative work between you and James Mickens -- this genre of writing seems sadly under-present in the computing world...

> But, I can do basically the same thing ... what am I missing about Sandstorm?

The big difference, in my mind, is that each app is integrated with a permissions/capabilities model and strongly sandboxed by individual instance or document. Sandstorm itself handles logins, and handles capabilities to access documents; then e.g. there's no way that Etherpad can accidentally leak your doc to someone else unless you've granted a Sandstorm-level permission to that person.

It sort of flips from the "walled-garden app" model, where the app is the boundary and individual docs and users are within the app, to the traditional "computer with filesystem" model, where the user login and the file with permissions are system-level concepts. (Except instead of "file", they call it a grain, and it's a separate instance of Etherpad or Gogs or whatever.) That's also what makes this more than just Docker containers -- deeper integration into the app.

That also gives you flexibility to have a bunch of different instances of a single app, and IIRC, they have functionality to import/export those instances in a well-defined format from one host to another.

At least, that's what I remember from playing with it 4 years ago. In any case, I got the impression that the model was much more secure, and flexible, than just "install Gogs on vanilla Linux".

ZIP+4 in the US is quite specific, though. E.g., my ZIP code is probably > 50k people but the ZIP+4 is just my apartment building.

Yeah, this should be roughly the same overhead as an ADD:

    LEA rDest, [rBase + 8*rPtr]

(The "load effective address" instruction computes an effective address like a load or store would, but just gives the address without doing a memory access.)

I've only encountered that once in the US but it was great as well -- Southwest at LGB (Long Beach, CA) had a separate set of air-stairs at the back door for boarding. I would guess it's not done more here because there are few airports that both board with stairs on the tarmac rather than a jetbridge, and also have non-regional (737+) jets where it would make sense.

That's not the goal of a VM/runtime, though: it only ensures that the hosted code cannot escape the sandbox, and provides a correct implementation of the semantics of each VM opcode. The hosted code's computation implemented with those opcodes is a black box to the VM.

Consider: should the VM somehow try to analyze the running code and determine when it's about to commit a logical error and return "forbidden" data? What specification states which data is forbidden?

Consider: even the most high-level VM can execute a program with logical errors if it is Turing-complete. A Java or Erlang program running on a bug-free, fully-compliant implementation of the respective VM can still get (e.g.) an authorization condition wrong, or incorrectly implement a security protocol, or return data from the wrong (in-bounds, but wrong!) index in an array.

My understanding of the issue, when I was in Pittsburgh ('09-'13 and '15-'19) was that it was a combination of Clairton Coke Works pollution and unfavorable winds/weather patterns that would cause the smell to stick around. I definitely know the smell he's talking about. But it wasn't every day, maybe not even most days (anecdata, I know), and not terribly strong where I was (Squirrel Hill).

Personal opinion: lots of cities have specific quality-of-life issues of varying degrees; in the Mountain View area now, I could equally complain about Superfund sites from all the early silicon industry dumping. Overall in Pittsburgh, the walkability, easy access to hikes through large parks in city limits, lack of stress about high rents, etc., probably outweighed an occasional whiff of sulfur wrt my quality of life. Everyone is of course welcome to make that tradeoff differently!

"Day After Trinity" is also a fantastic documentary in this area! It spends a lot of time on Oppenheimer's character and has interviews with a bunch of his former colleagues.

Yes, it records all syscall return values, so the replay doesn't actually need to perform them. This means that IO (GUIs, network accesses, etc.) shouldn't happen on replay, in general. (The replay does show stdout/stderr data, so perhaps those are special-cased?)

> I also understand it’s a very “sporty” city, which is something I’m not very into.

I wouldn't necessarily discount the city for this; in my time there, I realized there were really two Pittsburghs. You'll see the steel-town football-obsessed side any time you walk past a bar, but near the CMU/Pitt bubble it actually had a really intellectual vibe that I miss now that I've left. Not just the abundance of grad students, doctors and the like, but good libraries and bookstores, a fantastic symphony orchestra, a quality coffee scene, etc. Has a Portland/Seattle-like (including gray weather) vibe. And Steelers games are great times to go grocery shopping!

The travel situation isn't great though. PIT has direct flights to most east coast cities but getting to the west coast indeed sucks. (United does have a direct SFO flight, IIRC, if a bit pricy.)

Happy Fastmail user for 3.5 years so far. I particularly like (and am happy to support with my subscription fee) that they have active engineering staff building new technology and contributing it back -- in particular, their JMAP protocol work, which is an open standard [1], and behind the scenes their work to improve and contribute back to the Cyrus mail server [2]. Thanks and keep it up!

[1] https://fastmail.blog/2019/08/16/jmap-new-email-open-standar... [2] https://fastmail.blog/2016/12/12/why-we-contribute/

I don't have an answer to your question, but my favorite (cynical) example of this phenomenon is the Johnstown Flood Tax on all alcohol sold in Pennsylvania (set at 18%). The tax was originally meant to help the town recover. The flood was in... 1936.

That would still involve entering and leaving kernel mode, because timer alarms ultimately are triggered by a hardware interrupt (from e.g. the APIC timer or, in really old x86 machines, the 8254 programmable interval timer, aka IRQ 0). So IRQ -> switch to kernel timer IRQ handler (prologue saves all usermode registers) -> examine internal data structures, find pending alarm signal -> modify process state, pushing signal frame and setting RIP to signal handler -> return to userspace. That's probably slower than just Timer IRQ -> switch to kernel -> invoke scheduler -> decides to preempt, changes to new thread -> restore context, return to user space (but I'd be curious if someone actually measured).

Fundamentally, preemption has to originate from a hardware IRQ (or IPI from another core), so really the only way would be to kernel-bypass by setting an IRQ handler in userspace (ring 3). That's technically possible on x86 (IDT entry can have a ring-3 code segment) but I don't think the kernel has a mechanism for that...