brucehoult

If it's a pro then they'll be sitting in the back seat so you're in the front seat the same as you will be when you fly solo.

Here's a video of me taking a student for their first lesson:

https://www.youtube.com/watch?v=RDZN21xzsRo

That's in a DG1000, actually this exact one ZK-GGR:

https://www.youtube.com/watch?v=PeueijUoL70

https://www.youtube.com/watch?v=r0ShTUTiqlM

And how that looks from the other end of the rope:

https://www.youtube.com/watch?v=sRxcJR-zipI

And from the door of the hangar (using the runway in the opposite direction). Turn it up!

https://www.youtube.com/watch?v=RUnXuMVhKfs

Coming back to more like the current topic, an electric powered glider:

https://www.youtube.com/watch?v=7F2gS9ENl5k

Also from Stefan's channel, some fun here in New Zealand ... this flight passes just a couple of km from the Lord of the Rings "Weathertop" site (Google maps knows it).

https://www.youtube.com/watch?v=ggz2CzvPNUc

In sailplanes we add up to around 200 litres of water to wing tanks in single-seat gliders (empty weight typically around 280kg) to improve the high speed performance (typically up to 270 km/h these days) and ability to fly comfortably in turbulence.

It's surprising what you can fly formation with, even without an engine [1] :-)

https://www.youtube.com/watch?v=G0icOICQLTc

Dumping (most of the) water before landing:

https://www.youtube.com/watch?v=I4Yv-V7eozk

[1] this particular glider does have a small engine for takeoff, but maximum speed with the engine extended is 180 km/h and here they are flying at 280 km/h.

Many rather wide streets in the centre of New Zealand cities have had 30 km/h speed limits since ... I think the 1990s.

For example here, Willis St in Wellington:

https://maps.app.goo.gl/8hHCLxCDK4C8U8Tz9

You can see it is already 30 km/h in the first streetview capture in 2008.

I guess you missed Leela then.

And in 2020 Stockfish 12 adding some NN evaluation. And then in 2023 Stockfish 16 entirely removing the classical position evaluation code.

https://stockfishchess.org/blog/2023/stockfish-16/

Or Mojo, recently acquired by Qualcomm, and even more recently fully open-sourced under Apache 2 license.

That's how it works, yes, if the originator makes it freely available then so does ISO.

The 256 byte hardware stack is plenty for function return addresses and temporary use within a function. How deep are you planning to nest function calls anyway?

You can create as many other stacks as you want using pairs of Zero Page locations as stack pointers.

Best practice for recursive/reentrant code (e.g. compiling C) is to follow modern RISC/x86_64 practice and reserve a few (16 maybe) Zero Page locations as argument/working registers, a few (16 maybe) as callee-save registers, and have prolog and epilog utility functions that create/destroy a stack frame and save/restore N bytes of callee-save ZP locations.

You can unroll those into a sequence of elements like...

    lda $1F
    dey
    sta (SP),y
    lda $1E
    dey
    sta (SP),y
    :
    lda $10
    dey
    sta (SP),y

... at 5 bytes and 11 cycles per byte saved. And of course jump into the appropriate part of the sequence.

> I still prefer programming the Z80 over the 6502 though :)

I really don't.

There are some few things you can fit into and get working fast in the Z80's A + 6 registers (IX and IY are not useful if speed is the aim), but for anything complicated the 6502's 256 Zero page locations — any pair of which can hold a pointer you can index off — is far superior.

The Z80 is awful at accessing memory for anything other than a simple absolute address or sequential access or push/pop of a register pair. It's better for manipulating 16 bit values, but not as much as you'd think especially once you run out of three register pairs plus ToS.

Also I haven't looked closely but I don't know if you could find space to fit it in the remaining Aarch64 encoding space.

The existing a64 conditional branch instructions use a 19 bit field to hold the offset. Add two registers to compare (10 bits) and 3 bits to choose between EQ, NE, LT, LTU, GE, GEU and you're already at 32 bits before having an "opcode" field to choose "RISC-V style conditional branch".

Of course you could reduce the branch offset size down to RISC-V's ±4k which only needs 11 bits when you only have 4 byte instructions, but that's still a 24 bit chunk of unused opcode space to find.

Oh .. looks like 0b10xx is still completely unused. We could grab maybe 1/4 of it

So could do ...

    [31:28] (4 bits):  0b1000 (Fixed primary opcode .. or 0b1001, 0b1010, 0b1011)
    [27:23] (5 bits):  Rs1
    [22:18] (5 bits):  Rs2
    [17:15] (3 bits):  Cond (EQ, NE, LT, GE, LTU, GEU, + possible 2 more)
    [14:4]  (11 bits): Offset (Signed ±4k PC-relative offset)
    [3:0]   (4 bits):  0b0000 (Fixed minor opcode/extension identifier)

One problem here is this doesn't allow both 32 bit and 64 bit compares. And also the Rs1 and Rs2 are not in the usual places.

Maybe...

    [31:28] (4 bits): 0b1000 (Fixed primary opcode)
    [27:21] (7 bits): Offset[12:6]
    [20:16] (5 bits): Rm
    [15:13] (3 bits): Cond (EQ, NE, LT, GE, LTU, GEU, etc)
    [12:10] (3 bits): Offset[5:3]
    [9:5]   (5 bits): Rn
    [4:2]   (3 bits): Offset[2:0]
    [1]     (1 bit):  sf (Size flag: 0 = 32-bit compare, 1 = 64-bit compare)
    [0]     (1 bit):  0b0 (Fixed)

I think this fits other instruction formats better .. and gives a ±16k branch range.

Some ::coff:: would criticise the split up offset field. Not RISC-V fans of course. And this puts sf in a non-standard place.

Some more playing around is needed .. over to you Arm.

SVE2 is compulsory in ARMv9-A, but NEON is optional?

C-Sky and Andes NDS32 were popular enough to be supported by both GCC and the Linux kernel, both switched to RISC-V. ESP32 switched to RISC_V for all new chips.

Interestingly Synopsys's ARC's latest version ARC-V is RISC-V.

I think all major FPGA vendors now offer fully supported RISC-V soft cores either alongside their older proprietary ISAs or as the latest upgrade. Several (e.g. Microchip and Gowin) have included real RISC-V cores inside FPGAs.

Why? It'll still run fine.

Just like Debian still runs on original x86-64-v1 from 1999, not x86-64-v3 (needs AVX2,FMA, BMI1, BMI2, LZCNT) or even x86-64-v3 (needs AVX-512).

Similarly, Debian for arm64 still requires only ARMv8.0-A from 2011 not even ARMv8.2-A (everything from A75/A55 to A78/N1/V1) let alone ARMv9-A (A710, A510, X2 and on).

Why would they do in the RISC-V world what they totally haven't done in amd64 or arm64?

Not me for sure. I have no idea about you. Of household name companies I've only worked at Mozilla and Samsung R&D. And SiFive if you count people in threads such as this.

I could of course be wrong but I think the publicly known history sets the pattern pretty reliably for the speculation.

Such as?

There is still plenty of unused 32 bit (30 bit) opcode space.

I specified "popular 64 bit ISA", which comes down to amd64 and arm64. But you can include Elbrus and LoongArch if you want. Or POWER. Or Itanium.

> I assembly by hand almost any function that is not too simple I can make it shorter on Cortex-M33 than on RISC-V

Not if you use the RISC-V ISA properly.

You can choose Arm in one pair and RISC-V in the other pair if you want.

No, RISC-V code is much more compact than Amd64. This is easily demonstrated on any real application, such as those in your favourite Linux distribution.

It's not even double, because half of them are RVC-only decoders.

And Arm dropped a T16-like encoding entirely from their 64 bit instruction set.

If they did everything exactly the same they would be the same ISA not different ISAs.

It's just as easy to point to things that RVC can do that T16 can't.

You need to look at a far larger picture to decide on who made the better decisions overall.

There is zero chance that Apple doesn't have MacOS and iOS running on RISC-V in the lab.

They did that with x86 and Arm half a decade before any announcement about a switch, not to mention a number of other ISAs that didn't make it to shipping (e.g. M88k) and probably ones that word has never leaked about. IA64, anyone?

They're too large and rich and risk-averse to *not* do it.

History is much easier than prediction.

I'm with Jim Keller when he says that in time the fastest CPUs will be RISC-V ones.

> you can use the same base trick behind a carry lookahead adder

YESSSS.

I've been pointing this out for years and years.

By the point that you're looking at the same propagation delay as a common 64 bit adder you're decoding 64 chunks of 16 bits per cycle. That's 128 bytes, or a 32-64 instructions wide decoder.

That is so much wider than anyone is making or contemplating — or that even makes sense given the size of basic blocks — that it's just a non-issue.

It's not wasted when it makes programs overall smaller, as it does.

Ubuntu 24.04 LTS exists and needs only RV64GC and will be supported and enhanced for many more years.

Debian has no plans to require more than RV64GC.

RVA23 is a very good thing in certain markets, but nothing forces you to support it for a personal project.

And all modern high performance Arm and x86 cores do more fusion than RISC-V cores that are currently on the market.

Intel has being fusing `CMP` and `Bcc` since Core 2 and AMD since Zen 1.

This is

- already one instruction in RISC-V

- an *extremely* common pattern, often occurring once every 5 or 6 instructions.

Performance is subject to debate and quality of implementation and whether such implementations will ever be financed and made ...

But *code size* is a demonstrable fact.

RISC-V has by far the most compact code of any popular 64 bit ISA, and that was true even of RV64GC. The gap has only widened with RVA23.

Just load up your favourite OS (e.g. Ubuntu 26.04) for various ISAs in Docker and compare the `text` size of various binaries, individually or in aggregate.

In 32 bit ARMv7-M / ARMv7-A had a small code size lead over RV32IMAC, but this is reversed in modern RISC-V e.g. if you look at RISC-V Hazard3 vs Arm Cortex-M33 in the RP2350 (Raspberry Pi Pico 2) where you can trivially change one option setting in your project and recompile and test.

The only exception is that the M33 has a single-precision FPU, which neither the Hazard3 nor the Cortex-M0+ in the RP2040 have.

Luke is too modest. Something in the region of 5 million chips containing his hobby CPU have shipped since launch on August 8, 2024.

In the distant past (2002-2003) I used two niche languages for the same programs across PowerPC, x86, SPARC, and PA-RISC:

- Dylan

- Scheme

It helped immensely that both Gwydion Dylan and Chicken Scheme compile their respective niche languages to portable C code.

Now emitting LLVM IR is an even slightly better technique. Except for PA-RISC. So GCC 15 (or HEAD) and C generation it is ... it's not bad using modern headers with portability defines such as `uint32_t`, ability to return at least a pair of values in registers, or tail calls using all argument registers if you convert to CPS (as e.g. Chicken does)

BASE jumpers and wing suit fliers too.

On my SpacemiT K3 SBC with 32GB RAM (where models run on the eight A100 RISC-V cores with 1024 bit vectors) doing the same task I got 5, 5.8, 6.5 tok/s using gemma-4-26B-A4B-it-QAT-Q4_0.gguf, Qwen3.6-35B-A3B-Q4_K_M.gguf, Qwen3.5-35B-A3B-Q4_K_M.gguf. The corresponding dense models are more in the 2.5-3 tok/s range.

Kind of slow, but using only 14W of electricity so the Wh per task is twice as good as using my i9-13900 laptop with 4060 GPU.