I found this post interesting in that reguard: https://www.lesswrong.com/posts/thXohzXrWCA2EhZCH/mateusz-ba...

There also is an insentive to silently give prominent people (e.g. Linus) or reasearchers like this custom tuned system prompts or even more powerful models.

I suppose nobody sane would give their AI internet access (even read) while training it. Though if they did, I don't think they'd want this to be public, because how can you even protect against this?

I wonder how much this matters for python. As long as the important dependencies like numpy runtime dispatch RVV, it should probably be fine.

Zba would probably give a small boost. Zbb gives a substantial boost to perf for applications that use clz/popc heavily, but I don't think that would apply to python.

related: https://www.sifive.com/development-platforms/sifive-bigsky-s...

When does bigsky ship?

I really like what you are doing here, the state of inline assembly is a similar travesty to the state of guided codegen/autovec.

On concern I have is how this maps to ARM64 syntax, because ARM64 is massively overloading all mnemonics.

For example:

    ld1d z0.h, p0/z, [x1, x2, lsl 3]
    ld1d z0.h, p0/z, [x1, z0.h, lsl 3]

Have extremely different performance characteristics, yet would map to the same code:

    ld1d dst, p0/z, [base + idx<<3]

Imo this makes reading the assembly quite bothersome. I'm already not a fan of ARM64 doing the mnemonic overloading, but at least you can figure out the operation by looking at the same line further to the right.

Also, maybe I missed it, but how are you dealing with things like the /z modifier, pre/post-increment load/store and load pair? Or things like TBL/ST4/LD4?

Oh and how are the types going to work for RVV, where the type can't be determined at compile-time in all situations?

I haven't fully thought out that syntax yet, but it's a problem with AVX-512 in terms of its predicate operands too.

My hunch would be the following:

        sve_ld1d_scalar :: asm(base: [^]u64, idx: i64, #mask pred: u16) -> (dst: #simd[vscale * 4]f32) [
                dst  = %z0,
                pred = #predicate(indirect=zeroing) %p0,
                dsth: u16 = dst,
        ] {
                ld1d dsth, pred, [base + idx<<3]
        }

        sve_ld1d_gather :: asm(base: [^]u64, #mask pred: u16) -> (dst: #simd[vscale * 4]f32) [
                dst  = %z0,
                pred = #predicate(indirect=zeroing) %p0,
                dsth: u16 = dst,
        ] {
                ld1d dsth, pred, [base + dsth<<3]
        }

So the parameter is marked as a predicate with zeroing or whatever, and then `pred` is just a normal operand as the binding section specifies everything.

This is not current behaviour yet but it I am considering it when I need to specify this for even AVX-512 and RISC-V behaviour (which has multiple different possibilities).

> I was aware that some architectures had distinct floating point registers

Most ISAs do.

On x86 and arm scalar and FP registers are separate, it's just that they overlap FP and SIMD registers.

On RISC-V there are three separate register files for scalar, FP and SIMD. Although you can overlap scalar and FP in some minimal embedded configurations.

D'oh. I'm old enough to have written software which needs to care about the i387 FPU and yet here I am acting as though the floating point instructions use the ordinary scalar registers. Worse, I have a window open where I'm writing toy software that doesn't compile because it is asking to do an FPU operation on a GPR and rather than fix that, which would remind me that this can't work, I decided to alt-tab to HN and make the exact same mistake.

Already in the works: https://lists.riscv.org/g/tech-announce/message/782