psykotic

With a VM, a single byte can encode one of 256 subroutines/jump targets. On the 6502 processor, whether you're using JSR or JMP, your shortest option is a 3-byte instruction. That's a 3x code size reduction. Of course you pay a cost in dispatch overhead. Incidentally, there's also an intermediate option which is called a direct-threaded interpreter in the Forth world, where your VM code stream consists of jump targets rather than opcodes. That requires 2 bytes per operation rather than 3 while eliminating the table lookup to map the 1-byte opcode to the 2-byte jump target.

The 3:1 reduction doesn't necessarily apply to operations that would normally map directly to CPU instructions. But especially for that generation of 8-bit microprocessors like the 6502, as soon as you're working with 16-bit data (which you definitely want for something like Zork) you end up spending a lot of code space for even simple operations. There's a famous example of a VM designed for the 6502 explicitly for reducing the code size (and inconvenience) of working with 16-bit operands: https://en.wikipedia.org/wiki/SWEET16

Yes, there are lots of famous examples. E.g. John Chowning invented FM synthesis for musical applications but had to assign the patent to Stanford where he worked as a researcher: "The FM patent produced about $22.9 million in royalties for Stanford University (largely via the sale of FM chips for soundcards)." With a patent date of 1975 and a duration of 20 years, they must have received royalties until 1995 off every OPL family chip (used in Ad Lib, Sound Blaster, etc) and all the Yamaha instruments based on FM synthesis (I believe Yamaha had an exclusive license in that market). That's just one particular example I happened to remember, but every tech-focused university probably has a large portfolio of these sorts of patents.

> Shallow orgs can move quicker, but that isn’t free.

That's not intrinsic to shallow organizations. One common failure mode when scaling shallow orgs is consensus-based decision making that can grind everything to a halt. As you say, a flat structure with a few designated leaders as bottlenecks for all decision making barely gets you off the starting blocks. Conversely, a deep org can move quickly as long as each level of the management chain is given appropriate scope for autonomous decision making.

MSVC only received C99 support starting in Visual Studio 2015 and even then it's only partial (but enough for us). Actually, we'll probably use anonymous structs and unions, which are technically a C11 feature, but have been supported by all the major compilers for a long time before C11.

Yeah, Casey's work was a big inspiration. Much of the structure is my attempt at adapting Casey's format for my own goals.

Yes, they'll be available permanently. I talk about this in the FAQ in the repository, if you want to check it out.

I'm afraid this is going to be far beyond any 10 year old! I assume a pretty high level of intellectual development and ability to learn abstract ideas quickly, even if the formal prerequisites are minimal.

Hi. I'm the guy behind Bitwise. Long-time HN user. If anyone has questions, I'd be happy to answer them.

Modern discrete GPUs also have IOMMUs and per-context page tables. It's a large attack surface which has received relatively little attention from hackers so far compared to CPUs, but there are hardware-level security features in place.

Your question relates more to IPython Kernel than Jupyter per se. Fortunately ipykernel has out of the box integration with event loops, e.g. https://github.com/ipython/ipykernel/blob/master/ipykernel/e... for asyncio integration, and you can then schedule cell updates on the asyncio event loop as you would normally. To have events on the Python side generate visible updates in the Jupyter notebook you can use ipywidgets, for which the Python widget state in the kernel is automatically synchronized to the JavaScript widget state.

In case anyone might be mislead given the topic of this article, you shouldn't do base64 encoding with a general purpose routine like getbits(). Since 3 * 8 / 6 = 4 you can process the input bytes in groups of 3 to avoid straddling issues (ideally with an unaligned 32-bit load if they're fast on your platform). Then your inner loop will look like this:

    uint32_t triple = *(uint32_t *)in;
    *out++ = base64[triple & MASK];
    *out++ = base64[(triple >> 6) & MASK];
    *out++ = base64[(triple >> 12) & MASK];
    *out++ = base64[(triple >> 18) & MASK];
    in += 3;

(The 32-bit load can read one byte past the end of the buffer, so allocate extra space or stop the loop early.)

> However, for most freshmen, the math is simply beyond them in their first year.

You can introduce Lagrangian and Hamiltonian mechanics very early on if you're okay with hand-waving over some of the analytical details and presenting it mostly as a problem solving tool. E.g. David Morin's Introduction to Classical Mechanics does a great job with minimal formal prerequisites (freshman calculus is adequate for the majority of the book) though its exercises and problems, which are the book's highlight, will be too challenging for most freshmen.

I think a low-brow problem solving centric approach is ideal as an introduction to Lagrangian mechanics in particular (not so much Hamiltonian mechanics) since the advantages are so stark and obvious compared to the Newtonian formalism. You don't have to worry about how velocities and forces transform to write down the equations of motion. You just write down the Lagrangian and take derivatives. That's something every student will immediately appreciate.

Linux distributions are a different beast since they're mostly tracking a myriad of upstream third-party repositories overlaid when necessary by their own patch sets. And most of those upstream repos are by necessity highly decoupled from any particular distribution. Different distributions have different solutions to how they manage upstreams with local changes. E.g. OpenEmbedded uses BitBake where (similar to FreeBSD Ports and Gentoo Portage) the upstream can be pretty much anything, including just a tarball over HTTP, and local changes are captured in patch files, while others instead use one-to-one tracking repos where local changes are represented by version control revisions.

AOSP is closer to what you're imagining, but I haven't met anyone who thinks Repo (Android's meta-repo layer) and Gerrit (their Repo-aware code review and merge queue tool) are pleasant to work with. E.g. it takes forever and a day to do a Repo sync on a fresh machine. A demand-synced VFS would be very nice for AOSP development, even though it's not a monorepo but a polyrepo where Repo ties everything together.

Yes, that's what I meant by coverage of the relevant branches. But the good news is that all these partial, heuristic sources of information can be combined. E.g. for detecting function entry points, you can combine information from ELF/PE export tables (if present), function prologues detected by a linear scan, vtables, static CALL targets, dynamic CALL targets from run-time traces, etc.

That's an issue for static disassembly, which is step one of decompilation. Your snippet is a classic example that can throw off naive linear-scan disassemblers. Recursive disassemblers can handle it easily if (and it's a big if) they can identify the basic block entry points. If you have top-level entry points (which can also be a problem), the main problem for a recursive disassembler are indirect jumps that don't fit standard patterns like switch jump tables.

All of this gets easier if you can augment your static analysis with control flow traces from program executions with coverage of the relevant branches, so you don't miss basic block entry points.

CE/EE departments sometimes offer an undergraduate VLSI intro course where you learn the theory from a textbook like Weste and Harris and get to design and tape-out your own chip via the Cadence or Synopsys tools and then fab it through an MPW service like MOSIS or CMP. So, it's certainly possible to learn some hands-on chip design fundamentals in school, but if your department doesn't offer it, you're pretty much out of luck. You could do your own extracurricular MPW run of a small design for maybe a thousand dollars, but you'll be stuck with SCMOS cell libraries and free tools like Magic or Electric, which aren't representative of industry.

Regarding the lack of upstream work, a former Qualcomm VP told me that the major reason they minimize any open source work is that their lawyers are paranoid that any accidental IP leak might endanger their patent-related revenue streams (80% of their pre-tax profits are from patent licensing). Given that patents are public information, I'm not sure I understand the exact logic there, but I've seen this general kind of legal paranoia play out before.

Their non-Android Linux BSPs are especially bad since they're frankensteined together from a subset of their AOSP tree with their only concern being to meet the minimal requirements of some high-volume customer contract.

And ideally you just put all the debug info files on a server where they can be indexed by the build ID, and the debugger automatically tries to fetch the relevant debug info files when debugging a process or core dump. This is easy on Windows since dbghelp.dll (on top of which most debuggers are built) lets you put symbol server URLs in the symbol path list and it will automatically look up GUIDs there and cache downloaded PDBs locally for reuse. As far as I know, there still isn't a turn-key equivalent with GDB, but you could probably rig something up with Python scripting?

The next step up in convenience is having the source-level debugger understand how to fetch the corresponding source files from a server based on revision IDs or content hashes.

Between those two features, you can open a core dump on any machine, and immediately have access to both debug info and source without manually mucking around with anything. If you spend a lot of time looking at core dumps from a myriad of different programs and versions of those programs, this is a lifesaver.

Older NVIDIA GPUs (and maybe current ones) used an alternating-direction scheme for coarse rasterization which was called (somewhat tongue in cheek) boustrophedonic rasterization. The idea was to have more spatial locality for the coverage samples issued by the rasterizer compared to a conventional same-direction scheme. Spatial locality in the two-dimensional sense correlates to spatial locality in the texture cache, for example.

I'm fond of this old RAND report from Dreyfus, which is worth skimming if you're mathematically inclined: Dynamic Programming and the Calculus of Variations, https://www.rand.org/content/dam/rand/pubs/reports/2006/R441...

One important takeaway is that dynamic programming in the Bellman formulation is a discrete analogue of Hamilton-Jacobi theory in how it writes down an equation for the optimal value as a function of a given endpoint rather than writing down an equation for the path as with the Euler-Lagrange equations. (You can reconstruct the path from the value function after the fact by gradient descent.) The relationship between Hamilton-Jacobi and Euler-Lagrange is the classical version of wave-particle duality. A concrete example in geometrical optics is the eikonal equation, a Hamilton-Jacobi type PDE, versus the geodesic equation, an Euler-Lagrange type ODE. Not coincidentally, one common numerical method for the eikonal equation called the fast marching method is a dynamic programming algorithm, very similar to Dijkstra's algorithm for shortest paths.

It should be mentioned that any "local" equation like a PDE or ODE cannot describe a globally optimal solution without strong assumptions such as convexity. In fact, satisfying the Euler-Lagrange equation isn't even sufficient for local optimality without further qualifications (Weierstrass conditions). But the Bellman dynamic programming equation, being recursive, can describe globally optimal solutions.

UCSD Pascal had separate compilation units (late 1970s). A lot of people from my generation got started with Turbo Pascal and it had units based on UCSD Pascal starting in TP 4.

Sure, and the AFA has a pro-developer and pro-consumer side by reducing fragmentation. But I think it's important to understand that the open source aspect of Android is a small part of the story in practice for device makers. The narrative that Google is just "giving it away for free" is naive at best for the very reason you state: they're a profit-driven megacorp.

> It's rather sad that Google needs to pay Android makers a fee for installing it's apps, given how Google gives away source code that makes Android exist in the first place.

This is a very innocent view of Google's business practices in this area. Google has a tight hold over most device makers through anti-fragmentation agreements and other contracts if they want GMS and want early access to the non-public AOSP tree, which is a practical necessity to ship cutting-edge Android devices. Aside from hard legal power, Google also projects soft power through their control of the ecosystem and device makers wanting to maintain good relations. As a result, Android-derived innovation in the ecosystem is highly constrained even if AOSP is open source licensed since device makers and manufacturers cannot ship devices with Android-derived operating systems in device categories enumerated by the AFAs unless the devices pass CTS (which prevents most kinds of serious divergence from Android).

> Add a million LUTs and several thousand special-purpose blocks (ALUs, CAM, SRAM, DSPs, etc.) on CPU die that can be reconfigured within a few 10k cycles

LUTs are implemented as a cascade of muxes that are controlled by local latches that are set at configuration time through a scan chain. Scan chains are key to letting you configure all these LUT control latches across the whole chip in an area-efficient manner, but there's a severe time vs area trade-off since you're essentially configuring one LUT control bit (a vanilla 6-LUT has 2^6 = 64 control bits) per scan chain cycle per scan chain. FPGAs already suffer ~30x area overhead for LUT logic compared to equivalent ASICs, so adding a lot of additional area to enable much faster reconfiguration seems like a tough sell. Matrix addressing as used in DRAMs and LED/LCD displays is another sweet spot on the time vs area trade-off curve. Not sure if anyone's ever done an FPGA using that as the configuration topology, but it'd probably make a fun dissertation topic.

Quiet NaN is critically different from the Maybe monad's Nothing value. Maybe gives you proper exception semantics even if it's implemented by means of predicated data flow rather than early-out control flow (and in a pure, non-strict language like Haskell there isn't a real distinction between data flow and control flow). Whereas quiet NaNs have a significant issue with non-termination where you have to very carefully express all your loop conditions positively. For example, 'while (x - y > eps)' will terminate if either x, y or eps are NaN, but any code that relies on 'if (positive_condition) break' and similar constructs for termination will loop or recurse forever if the condition operands become NaN.

A closer analogue of NaN might be the x ("unknown") value in the three/four-valued logic of hardware simulation languages like Verilog. But the situation in Verilog, despite its challenges, is so much better since you don't have a hard discontinuity between "numbers" and "logical values". Numerical comparisons between unknowns can produce unknown logical values, and you have equations like true & unknown = unknown, true | unknown = true, ~unknown = unknown, etc, so you don't have the issue with NaNs where as soon as something crosses from the floating-point realm to the integer or logical realm, it has to commit to a definite value, with all the aforementioned issues.

All that said, NaNs were the right design choice given the constraints. But it's far from ideal.

Thanks for the correction; I thought 6 mm sounded way too high. Gotta love American measurement units!

There are Internet accessible Chinese PCB manufacturers that will do short runs for designs of almost any complexity, but they aren't really targeting hobbyists, though that seems to be changing.

I was about to suggest SoMs as well.

The biggest challenge with BGAs from a hobbyist perspective isn't the soldering. There are lots of hobbyists successfully reflowing BGAs with toaster ovens. The bigger problem is manufacturing the PCBs to break out the BGA balls. TI has some BGAs with a proprietary ball pattern that are designed to be broken out with just 4 layers, but that's the exception, and you generally need very narrow traces and trace clearance to route between balls and vias. I just looked at OSH Park's current capabilities and they only do up to 4 layers and their DRC specifies 6 mm minimum trace width and 6 mm minimum spacing. I've heard of people using OSH Park and similar lower-end prototyping services to manufacture one-off PCBs for fine-pitch BGAs, but you'll be failing DRC by a massive margin, so expect terrible yield on the PCBs, assuming any of them work at all.

Unfortunately I think DRC will be similarly challenging for most SoM connectors since their pin spacing has a similar pitch to BGAs, so you'll probably need an off-the-shelf break-out board to work around that. Honestly, at some point you should consider whether a vanilla dev board with low-speed GPIO headers could meet your requirements.

This reminds me of a tool Jeff Roberts wrote at RAD Game Tools which would repackage libraries so they were loadable on Linux. At the time the motivation was that MSVC was generating much better code than GCC for Bink, so he'd compile on Windows with MSVC and cross-link to Linux with his custom tool.

The 6502 chip design used precharging for exactly that reason. You precharge to Vdd in phase 1 through a path with high drive strength and then in phase 2 only the fast pull-down network has to do any work if needed. The pull-up network is still there to prevent floating and hence needs to be ratioed against the pull-down on-resistance to pass a strong 0, but the pull-up resistance no longer sets the low-to-high switching time. The main limitation is that it can only handle monotonic logic, so you may need to interpose static inverting logic stages between your precharge logic stages.

And in standard chips nowadays, you can still find transmission gate logic (complementary pass transistors so you can pass both strong 1s and strong 0s), pseudo-NMOS logic (using a boring old enhancement mode PMOS transistor tied off to ground as a pull-up resistor) and domino logic (precharge logic with interleaved CMOS stages) in critical datapath circuits, so even in a bog standard CMOS process there's room for trickery.

> The drawback is that it's harder to manufacture a chip with both N-channel and P-channel transistors.

Yeah, and CMOS wasn't competitive for higher speed chips until the 80s (the 68000 was NMOS based until 1985 and some higher end processors eschewed MOS and used bipolar ECL). CMOS had been around for a good while at that point but was mainly used for applications like battery-powered watches and calculators where static power draw was more important than speed. The 65C02 (a CMOS version of the 6502 with a few other features thrown in) came out in 78 and was competitive in speed to the original 6502, though it was originally designed for a customer for use in calculators, but of course ended up being used in numerous home computers.

Zynq. Yes, their SoC products have embedded ARM cores: https://www.altera.com/products/soc/overview.html

These's a bunch of affordable Cyclone V SoC development boards: http://www.terasic.com.tw/attachment/archive/836/image/compa...

> Apparently the r&d costs in this space are higher then lawyer fees. Otherwise why wouldn't they dump some money into r&d and get some patents of their own to cross license with Qualcomm.

I'm sure there's plenty of cross-licensing already, but Qualcomm gets close to 80% of its pre-tax profits from patent licensing, so they have asymmetric incentives and are in very different bargaining positions. (Source: http://www.economist.com/news/business/21715705-its-biggest-...)

I'm highly skeptical of patents as a whole, so I do find it hard to cry tears of sympathy for patent warmongers like Intel, Samsung and Apple, even if Qualcomm is a particularly bad actor.