Comments URL: https://news.ycombinator.com/item?id=49445418

Points: 16

# Comments: 1

2. That was a bug and it has now been fixed, along with many other analysis bugs.

3. The sorting algorithms are getting an overhauls soon to be a lot faster.

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]
        }

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).

And where is the AT&T? Did you even look at the syntax or read the article? Is it just the use of `%rex` to prevent namespace collisions with parameters and constants which could hypothetically be named `rex` (and there could be good reasons they are named that too)? There are no other sigils in the grammar. The order of the operands is Intel-like. The memory operand syntax is Intel-like.

And I do not even seen why a universal syntax for such ISAs is impossible to support either at the syntax level. Hexagon's `.new`/`:sat`/`:<<1` stuff could be easily added into the universal syntax (with a better syntax), even if other ISAs do not support it. Same with SHARC's parallel-operation separators: you just pick a different syntax.

Even now, the full `[base + indexscale + disp]` syntax is not semantically supported for RISCV64 because they do not support `indexscale` in their memory operands.

Yes the prefix syntax is a quirk but if can tell me an alternative syntax that is context-free to solve this problem that is also not too stark nor dense too read, please do! I am open to new ideas, but it seems that even other assemblers like Plan9, Go, and D, all came to similar conclusion with `lock; xadd ...`.

And the article was not LLM written.

Well I assumed so because amd64 is a superset of x86. But nice to know you're working on arm64 too.

Regarding Intel-syntax, I think there is a little miscommunication here since I try to explain what I mean in the article. Intel-ordering is a good idea, but using nothing but the Intel-syntax wholesale is not universal enough, and needs modifying, especially for AMD64 and other ISAs. Odin's is Intel-like too, but fully Intel by design.

> That's so the source code can be tokenized and parsed without needing special behavior inside the asm { ... }.

This is why Odin's asm templates have their own universalized syntax. Thus the entire article.

> Not sure what you mean. RAX means register RAX. %RAX is not accepted.

This: https://github.com/dlang/dmd/blob/master/druntime/src/core/i...

It's why I referred to your "trick", which is something I wanted to need in the first place.

> That just makes it easier to parse!

For Odin's asm template syntax, it's not about being easier to parser, it's about having a context free grammar that is the same across ISAs. If I was to allow for prefixes directly in the grammar, either prefixes would have to have their special syntax or you'd need to have a context-sensitive grammar.

I really like it when he does because it allows me to see what he has done for D, and learn from it.

D's inline asm is also statement-based rather than a callable template. Though the mixin trick fixes this, it does mean it still uses %0-style parameters making it hard to read and write, something I want to remove completely.

It is great to see that we arrived at similar design compromises, especially regarding `lock` being treated as a separate instruction and thus separated with a `;` (which is automatically inserted by the Odin compiler).

And we already track all of the basic side-effects and clobbering that each form of each mnemonic does. That's kind of the entire point of this being possible: it's all "typed".

Which we have massive tables for each form which track those side effects and clobbering information too.

> author/LLM

I am the author, and not an LLM.

> Tomorrow you need to pass a 128 bit int into two registers

Okay? There are no 128-bit integer registers on AMD64, ARM64, nor RISCV-64. So I have no idea what you are on about. And note they are templates, so if you want 128-bit integer support, you can just wrap that template in a procedure and handle the behaviour yourself.

And from that huge table of type information, this can be used to give good error messages and suggestions to the user because the compiler actually knows all of this. The type constraints here allow for a lot more than information that normal assemblers just don't give.

add_three :: asm(my_in: u64) -> (my_out: u64) { add my_out, my_in, 3 }

out_var = add_three(in_var)

Which is already infinitely more readable and requires no parochial sigils nor the arcane clobbering syntax.

TALs are also solving an entirely different problem.

Comments URL: https://news.ycombinator.com/item?id=49351408

Points: 3

# Comments: 0

The answer is "yes" depending on what you mean by STM32 :D

But if it's one we don't currently support officially, it should be pretty easy to support too, with probably a little extra assembly.

I didn't say that either nor even imply it, and you know that when you quote me afterwards. So huh?!?!

> People don't use Linux because they enjoy tweaking config files and everybody else has too busy a life to do that.

A lot of people, including younger myself, got into Linux and Android BECAUSE it was configurable and customizable. And even played around with all of the customizations because it was fun to do. But it didn't really make my general experience better because I was forever trying to correct something I should have to correct in the first place.

I am not sure how much clearer I can be in the article or in my replies to comments.

And there is the problem. The first time you do the edit, it might be fine, but when you make a mistake in the edit, you then have to go back and correct all of the cases. With multiple cursors, I am seeing instant visual feedback on all instances of the cursor at once. I am getting literally 2D spatial information, compared to the 1D spatial information per each replay. The multiple cursors approach is better not because it's a different mindset or whatever, but rather it produces a different feedback loop to correct mistakes.

If you still prefer the macro approach over the multiple cursors approach, then you do you. But as an example in the article, I have seen people think they are being productive by their own standards, and they really aren't.

If you are having fun, and it's a hobby: who cares? If it's in the professional setting, make sure what you are doing is not actually wasting time and/or money, i.e. be productive.

That visual feedback is EXTREMELY useful because I learn of the edge cases to what I am editing in bulk (usually formatting code or tables or whatever) as I am editing it. When you do a macro, you have to try and get it right, and then try again from the start each time to get it right. `dot` et al are not enough in that regard. So the multiple cursors approach is better not because it's a different mindset, but it produces a different feedback loop to correct mistakes.

If you still prefer the macro approach over the multiple cursors approach, then you do you. But as an example in the article, I have seen people think they are being productive by their own standards, and they really aren't.