RetroTechie

And yet, a good portion of software that runs today's world is written in scripting languages & executed using interpreters.

Which is okay! Imho: multiply [# of users] with [how often each user sees that software's effect] and [how much that contributes to the overall user experience], then you get a ballpark idea of how much $$/effort is worth spending on optimization.

In other words: for a one-off, don't bother. But as usercount, frequency of use by individual users, poor UX or RAM/CPU consumption goes up, progress from script -> compiled -> optimizing compiler -> (if necessary) hand-optimized assembly as needed. And of course consider high-level design, data structures, algorithms etc in that process. A change there might be more effective than a switch from interpreted -> optimizing compiler.

"Developer time" should not factor into that much (again: imho) unless users=developers.

Thoughtlessly putting every change through a (slow?) pipeline that does 'random' toolbox-of-optimizations without need, is wasteful. Apply that toolbox as needed while keeping the above in mind.

I propose that you put up a webpage (or site) explaining in excrutiating detail what's the problem(s) you're facing right now. And do so quickly. Say, in a week or so.

Then, invite the public to tear that apart. Just maaaybe they can come up with unorthodox / creative solutions that NASA or Katalyst engineers have overlooked, and might be doable in the remaining time.

Maybe I could pitch in with an idea myself. But before doing so, I'd like to be able to read up on where you're at - in detail. "Ongoing attitude control issues" doesn't cut it.

Crowdsourcing (smart cows) is a thing. And satellites are precious. Please don't give up on Swift before there's really nothing left that you can do.

Hmm yes, 'everybody' in the NL is aware of that.

> In the latter case, they sometimes left those strips of land to transport the fuel.

Not really. The turf blocks would be stacked in piles & left to dry for a while. But then often transported by boat (through the newly created channels). The leftover strips of land could be used to have men, or a horse, pull such boats on a rope.

  MSX-DOS (1) uses FCBs and a single root directory
  MSX-DOS (2) also uses file handles and supports subdirectories

Yes Microsoft was involved here too. Note that MSX-DOS offered some CP/M compatibility: some programs pulled straight from CP/M (Z80 flavour) could run under it. Some functions deal with CP/M-derived 128-byte "records" (from CP/M floppy formats' sector sizes) rather than byte sizes. But no CP/M disk formats were supported afaik.

Other than that, MSX-DOS2 offered some memory management functions for MSX2's memory mapper. Not sure if equivalent functionality was included in MS-DOS 2?

Like most lakes in the NL these tend to be shallow (~1.5-2m depth is common, even the biggest lake -Ijsselmeer- is only about 5..6m in deepest areas).

Perpetrator loses/wipes whatever device used to interfere with the Wi-Fi. Starting with passenger list, it could have been anyone, right?

I'm not talking about zooming in on most likely suspect(s). I'm talking about proving (legally) it was them rather than any other passenger. Never mind theoretical possibility of a device dropped/hidden somewhere on a previous flight of the plane, doing its thing after 'dropper' went elsewhere.

https://en.wikipedia.org/wiki/Register_renaming ?

But yes, register count is still a thing. Why? If you run out of registers, operations 'spill out' into main memory. Read: L1 (data) cache. Which is fast, but not as fast as CPU registers. And probably uses a lot more transistors & power.

Of course there's limits to that due to # of opcode bits available (eg. 32 regs, 3-operand instruction -> 15 bits needed to encode source & target registers).

x86 hit that sweet spot: 8088/8086 performance nicely between much-weaker, memory constrained 8-bitters and too-expensive SPARK/MIPS/Alpha etc workstations. Then the BIOS situation opening the door for PC clone builders, Intel's good fabbing, and presto: x86 took off. People just bought PCs because economies of scale provided increasing bang/buck compared to other offerings.

ARM: grew steadily in embedded. Then "mobile" became big, ARM was objectively better than x86 there (battery! perf/W), and the market size provided huge $$ royalties that enabled ARM to hire top-talent engineers & improve their next designs. Leaving their competition in the dust. Steadily upping performance lead to things like ARM based laptops & servers.

RISC-V is largely riding the "open" wave. Which does translate into practical advantages like driving down product cost, software support improving fast due to the shared ecosystem, etc. But again: much luck involved - timing of its introduction, cheap FPGA boards becoming available to developers & students, the ISA itself being fairly sane (even called "boring", which is good in this context), its modularity positioning it across a wide range of markets, coumtries like China looking for tech-independence, etc.

This much like ~1850's industrialisation in Britain: ANY one of the factors missing could have lead to failure.

Personally I have high expectations for RISC-V. But regardless how it'll pan out: it's well past critical mass, so it's here to stay.

Whatever leading-edge fab capacity (mostly TSMC) was available, is now tied up to supply the ongoing AI boom. And will remain so for the foreseeable future. Even if you'd have a RISC-V product for which demand/economics work out, chances are those fabs' order books are filled.

Also: design is done in many places, but actual fabrication of RISC-V SoCs in largely centered in China. Which (afaik) doesn't lack IC fabrication capacity. But does lag in leading-edge fab capacity. So: off to older nodes. Which may hurt perf/W, cost effectiveness or transistor budget. Or pay a premium (pricing products out of markets), limited production, or long lead times.

Of course this affects ARM based & other products too. But they've been in the optimization / mass fabrication / distribution pipeline much longer than most RISC-V based products. Catching up takes time, and top-tier fab capacity being swiped by Nvidia & co doesn't help to shorten that process.

I don't think it's a demand problem. Consumers don't care what powers their phone/tablet/laptop as long as it does its job. So in principle the market is there (yeah.. I understand issues like Google still working on Android-RISC-V, Windows users probably wanting x86 for legacy software etc).

Yup.. If author's working with a RISC-V softcore, there are several options to reduce interrupt latency:

  # If softcore saves many registers as a hardware feature: adapt it to not do so
  # Save (and use) only a few registers in interrupt handler
  # Reserve some registers to be nuked by the interrupt handler, and don't use those in application code
  # Use another softcore with faster interrupt response
  # Move to a part with cpu as hard silicon (with sane interrupt handling)

RV32 and RV64 are considered distinct ISAs. But designed to divert as little as practical.

Apart from the register size, differences are small enough to be (almost!) irrelevant. If you know RV32I assembly, then you know RV64I assembly & vice versa. Moving code between those is at worst a re-assemble away. Also it should be easy to support execution of RV32 binaries in userspace on a RV64 cpu (if some implementations supporting that don't exist already).

AIUI, profiles were meant to provide a common target for eg. Linux distributions. Cases where you want 1 "generic" binary to support a variety of hardware like phone/tablet/SBC/desktop. Since these target the common case, yes profiles can be expected to grow & accumulate legacy cruft over time just like other ISAs. But for embedded or high-performance computing (HPC), this doesn't matter as code will be compiled for the specific hardware anyway. RISC-V's modular ISA is a great asset there.

In the meanwhile: loootts of legacy cruft dumped (esp. compared to the insane x86 world). That's always welcome. Nothing's fixed in stone (not even silicon, imho), and tech should learn from past mistakes, improve things & move forward.

Discussions tend to fall into 'AI fans' highlighting pros: AI-assisted coding at superhuman speed, breakthroughs in long-standing math puzzles, AI-enabled advances in science like new drug discovery, etc.

Then there's the critics: railing against datacenter buildouts, their energy consumption / environmental impact, job losses, geopolitics, open vs closed models, etc.

And of course new models, their performance, hardware required & so on.

But what about the risks? One can argue plausibility & probability of various scenarios. But risk of any such scenario unfolding hasn't disappeared, has it? And these risks are only increasing as AI-powered systems are given more eyes, ears, hands & feet, while taking humans out of the loop.

I wouldn't count myself hard into any of above camps. Overall AI is a mixed bag of enormous potential, pros, cons, limitations, uncertainties & unpredictability all around. But risks are real & worthy of discussion @ length, imho.

(btw love that AI 2027 site)

More like early 90's. In the late 80's it was still common & easy to order schematics, data sheets/books & the like from manufacturers. Usually @ cost, sometimes as a free service.

https://www.amnesty.org/en/latest/news/2026/07/shell-nigeria...

"Nigeria: Shell documents expose ‘basket’ pipeline, ‘missing’ wells and US$10.9bn decommissioning costs as pollution scandal grows"

But model(s) implemented are clearly too small to be useful as a 'chat partner'. Tried a couple of sentences - replies is just some gibberish coming out.

This really needs a bigger FPGA, or some other application(s) where a tiny LLM does actually useful work. Barring that, generated tokens/sec is kind of a meaningless measure imho.

As it will be for most software, imho. There's a limited suite of extremely popular software, and some locale-specific ones. Everything else is buried in a mountain of "the rest", where it's near-impossible to discover what's worth one's time (read: so >99.99% of potential users won't bother, and stick to well-known apps).

Logical consequence is that most of "the rest" turns into abandonware.

Big Tech's algorithms behind what's promoted on app stores, commercial interests, use of AI: all just make this worse. I don't see easy solutions to this problem. But if/when found, I suspect it'll be through community-run / grassroots efforts. "Monetization" otoh just turns everything to shit...

That paragraph + illustration is one of the simplest, concise, easy-to-grasp descriptions of IC design process I've come across. Nice!

Now the reverse: what I'd really love is a free (libre) automated toolset to go from IC die shot(s) -> transistors+interconnects -> gate-level schematic (logic gates & flipflops). Person interested in RE a chip's function can take it from there.

To me, the whole "here's a section of the die photo" to "that's an n-bit adder" etc step is like black magic. Not to mention extremely tedious.

Get that to a higher-level view easy, and it would be much more doable to work out function of each element.

Really simple ICs with a few counters etc in there might be possible to RE this way. Complex ICs with lots of internal state, memory blocks etc like a modern-ish GPU? Not a chance.

Some hybrid approach? Software fiddling with the chip's internals, with say. a big FPGA attached to physically probe outputs? Architecture docs, and maybe some IC die shots at hand? Perhaps (hence my ask for "detailed").

Sounds like requiring the kind of hardware setup that would not be available to uni students.

Either CD player would play audio itself (passed over analog audio connector), with the game occasionally changing track #. Zero CPU time.

Or a DMA controller would read digital audio from the CD, and CPU pass that on as-is to audio hardware. Lots of audio data streaming, but easy on the CPU.

Supercooled water is a thing: (and I've seen it a few times myself)

https://en.wikipedia.org/wiki/Supercooling

That said: 2KB RAM is tiiight even with application code in a ROM cartridge. No regular keyboard, nor a joystick port.. sound?

Not a great target to code anything for imho. Plenty of Z80+TMS9918A based contemporaries (MSX, ColecoVision, ...) to choose from.

Probably this. How would we know what such 'proto-life' (perhaps even just some self-replicating soup of chemicals, no cell wall) would look like? Where to find it? How rare its occurence? Etc etc.

Scientists might not even recognise it if happened right in front of them.

I'd put my money on coming up with a more general definition of "life", and then looking for short(est) pathways from "soup of random chemicals" to "something in there that replicates (parts of) itself".

Doesn't need to look like life as we know it, as long as some elements of "self-organising structures, something being replicated" are there.

Indeed. This is why conservation of habitats (however small, or degraded) makes more sense than trying to restore already-destroyed areas.

That said: if I could pick an area to work on for myself, I'd go for a stretch of wasteland. Why? Because the before-after difference would be more stark (read: more satisfying). And heavily degraded lands are in muuuch bigger supply than little-degraded areas.

More important would be a general willingness of the locals to not interfere with restauration efforts.

> I like this article because it demonstrates that there is always fertile land and opportunities where people are not looking.

Stronger: "fertile" isn't strictly needed. Fertile soil can be built - if necessary, starting from 'scratch' (yes it does take time). Basically: grow stuff (anything is better than nothing), mulch (bio-waste is free), keep doing so, and whatever soil you started with, will improve over time.

As the soil improves, plants grow better & other life returns.

Before AI, the only question was who made a particular artwork. Human-created practically a certainty.

When AI-generated art was new, it was all exiting & the process described to boast about AI capabilities or the skills of people deploying AI. But human-created still the default assumption.

Now, AI-generated <anything> is everywhere, and that default assumption of "human-created" is often questioned.

The natural next step is "AI-generated" as default assumption, unless claimed / shown (or even proven) otherwise.

Imho: assumption is the root of all evil. Investigate! Or take an author's word for it unless they're shown to be a liar. But as another commenter noted, it's a kind of tragedy of the commons. Methods to prove you as a human created <artwork> will be a thing.

But it IS crucial for removing bottlenecks & replace fossil fuels.

But it's different. Certainly not for everyone (imho that makes it even more interesting). So yeah, shouldn't hurt the HN audience to pop by now & then.