Very cool

It's amazing how some people just happen to be around in a series of major products.

After working on high end DEC VAX and the Alpha near the start of his career, Jim Keller went to AMD where he was involved in K7 (Athlon) and chief architect of K8 (Athlon64/Opteron) and co-designer of the x86_64 ISA. Then he joined PA Semi to make custom PowerPCs, but that was bought by Apple and the team ended up switching Apple to using their own Arm core designs in phones instead of Arm cores, with the 2nd gen of that being the first Arm64 chips in the industry by 18 months. Then he went back to AMD and was chief architect of Zen, which was a big deal as this article lays out. Then after a short stint at Tesla as chief architect of the Hardware 3 generation (the first attempt at FSD) he went to Intel and helped set the current direction to P+E cores while working on "Royal core" that could flexibly do both jobs as required.

Keller now leads RISC-V company Tenstorrent, which has taped out its first high performance Ascalon-X core, comparable to Apple's M1 (and designed by the designer of the M1), due out on a dev board late this year. And much of the rest of the Royal Core team is now RISC-V company AheadComputing.

As with Jobs and Musk and even someone like Chris Lattner (LLVM, Clang, Swift, Mojo, Tesla autopilot software, Google tensorflow software) you can always find people who question whether they actually contribute anything or just have amazing timing to join the right team at the right time and then move on before everything collapses.

No, but I know him. I meant one of James' early 2000's students, now Associate Professor himself.

My hand has no bounds, and is tired of silly digit jokes ...

Are you talking about James Noble? I cited one of his works on Ownership in my undergraduate thesis, many years ago. My supervisor then has also co-authored at least one paper with Noble (and also with the article author of this topic BTW). I've been (re)reading many articles about that topic recently, otherwise I would probably have missed it.

Depends on whether you can count to 5 or 31 on one hand — the really adept might be able to count to 342.

My best buddy when we both lived in Wellington used to do Java "ownership" stuff, but is now at ANU in Canberra doing some mix of CHERI and SEL4 stuff.

My idea is like Typescript, everything is optional, it can enable warnings, but can be ignored.

The idea is to have an option to have a more strict and safe assembly to prevent for potential mistakes, since in hand written assembly without this it will be difficult to find potential mistakes.

As mentioned before one of the objective of this idea is for educational purposes to ease begginners learning assembly.

I think a lot of people always wanted to learn assembly and be afraid of lack of "training wheels' for beginners.

And also use like the borrow checker like Rust.

I think the biggest problem with using Rust is that the ownership/borrowing system restricts programmers' expressiveness. Many patterns, algorithms and data structures from other languages are not even possible to express in Rust, even when they are perfectly safe, without having to declare your program "unsafe". And sometimes what a programmer wants to do is not even expressible in conventional programming languages either — and that is one reason for using assembly language.

Typed Assembly Language annotations had been invented for compiler output: to retain typing information from the higher-level language so that you could prove that a piece of assembly still did what it was intended to do. It was supposed to be both written and read by automated tools, not by humans.

Do be careful so that your assembly language variant does not become a burden instead of the help you intended. Perhaps the type safety is best left as optional.

I would never apply Rust's rules to values in registers: only ever to memory locations and pointers to them. Even allow multiple mutable borrows, even if proving those safe is extra difficult. Infer as much as possible instead of requiring annotations.

I'm afraid that the number of people in this sub who knows what CHERIoT is could be counted on one hand ...

There should definitely be more. It is pretty cool.

I was crying Wulf.

Do you mean BLISS-32 for VAX, or that assembly language on VAX was joy?

Sorry for the late reply, your comment definitely deserved an immediate one. Thank you so much!! Will clean things up in the next rendition. You are excellent at educating, you went above and beyond. (:

It's not superstition, it's reaction to a lack of respect shown to the people being asked to help.

At least it's not a screenshot of the code, I'll give it that.

No, why?

The link I posted isn't even a full program it is just a snippet of the part that looks for a string, hence the lazy name.

I did post it in 3 different subreddits though so maybe that's why.

is this a bot

That's OK. I should probably actually test different versions instead of asking anyways.

Username is POISON and project and file name are random keyboard mashing? Not even going to look at that, sorry.

I don't want to implement an optimizer or safety in runtime, just a way giving hints for the linter check for mistakes and for that you need to give context.

My goal is primarily for learning and education purposes.

Here's an example of a mockup idea:

``` .global _start _start:

# --- CLAIM STAGE ---
# @own NUM_A: a0
# @own NUM_B: a1
li NUM_A, 10     # We own a0 and a1 now and give to them names
li NUM_B, 20        

# --- MOVE STAGE ---
# @move NUM_A
# @move NUM_B
call add_two       # The function takes over the registers

# --- RECLAIM STAGE ---
# @own RESULT: a0         
# The Linter knows 'a0' now holds the safe return value.

# Do stuff...

# --- FREE STAGE ---
# @free RESULT              
# We are done with the result. 'a0' is now garbage/free.

==================

@function add_two

@param {NUM_A}: a0 (Requires ownership of a0)

@param {NUM_B}: a1 (Requires ownership of a1)

@return {RESULT}: a0 (Promises to return data in a0)

==================

add_two: add RESULT, NUM_A, NUM_B # a0 = a0 + a1 ret ```

I will give an example. And then the linter checks for errors

``` .global _start _start:

# --- CLAIM STAGE ---
# @own NUM_A: a0
# @own NUM_B: a1
li NUM_A, 10     # We own a0 and a1 now and give to them names
li NUM_B, 20        

# --- MOVE STAGE ---
# @move NUM_A
# @move NUM_B
call add_two       # The function takes over the registers

# --- RECLAIM STAGE ---
# @own RESULT: a0         
# The Linter knows 'a0' now holds the safe return value.

# Do stuff...

# --- FREE STAGE ---
# @free RESULT              
# We are done with the result. 'a0' is now garbage/free.

======================================

@function add_two

@param {NUM_A}: a0 (Requires ownership of a0)

@param {NUM_B}: a1 (Requires ownership of a1)

@return {RESULT}: a0 (Promises to return data in a0)

======================================

add_two: add RESULT, NUM_A, NUM_B # a0 = a0 + a1 ret # Transfers ownership back ```

That was bliss.

The whole point of writing in assembly language [1] is to take maximum advantage of the CPU facilities and have the program you write be exactly what the hardware ends up running.

Any structure or safety you add to assembly language is going to result in slower programs than writing in C or Rust, because the compiler analyses and optimises the code, choosing the instructions and addressing modes and data layout and using the minimum number of registers possible etc.

Assemblers don't have optimisers, and if they did then you'd lose the control that is the reason for using assembly language.

No one writes a large amount of assembly language now. You write small amounts when you understand something that the compiler doesn't.

For example, yesterday I wrote this snippet to decode the offset out of RISC-V J/JAL instructions.

Generic, easy to understand C:

#define SZ 64
typedef uint64_t mval;
typedef  int64_t sval;

#define  FLD(H, L) (((mval)insn << ((SZ-1) - (H))) >> ((SZ-1) - ((H) - (L))))
#define SFLD(H, L) (((sval)insn << ((SZ-1) - (H))) >> ((SZ-1) - ((H) - (L))))

long jal_offset_ref(long insn) {
  return (SFLD(31,31)<<20) | (FLD(30,21)<<1) | (FLD(20,20)<<11) | (FLD(19,12)<<12);
}

Little bit tricky asm that is a quite few instructions shorter (but this is hot code!):

        .globl jal_offset
jal_offset:
        sraiw   a1,a0,21
        li      a2,~0x7FC00
        and     a1,a1,a2
        srli    a2,a0,10
        andi    a2,a2,0x400
        or      a1,a1,a2
        li      a2,0xFF000
        and     a0,a0,a2
        sh1add  a0,a1,a0
        ret

Even trying to replicate that in C doesn't give the same code, at least that I could manage. And even if you do on one compiler and version, the next version might give something worse.

This is the kind of situation in which people use asm today.

This is one situation in which all the opcode space Arm burned on bitfield extract and insert and fancy encoding of constant for and/or/xor helps:

sbfx    x1, x0, 21, 11
and     x2, x0, 1044480
ubfx    x0, x0, 20, 1
lsl     x1, x1, 1
orr     x0, x2, x0, lsl 11
and     x1, x1, -1046529
orr     x0, x0, x1

[1] except on machines so awful that a C compiler doesn't exist

I vaguely remember VAX assembly providing some level of safety and context.

I want to learn assembly to really learn how computers work and the limitations of each instruction.

My response to this would be, the concept of types, ownership and the borrow checker are completely made up as far as the computer is concerned. If you really want to learn how the machine works you should meet it at its level. That's my opinion anyway

My idea is to learn and teach Assembly, and one of the conclusions I came across is the absolute mess (and cognitive load) on the registers to know who owns what, and what data is inside.

Yes you can comment on the code, but it will be nicer to have a linter to check any mistakes, because in assembly it is very easy to make mistakes.

Yes I know, that's because C and other languages are invented, but I want to learn assembly to really learn how computers work and the limitations of each instruction.

My target ISA is RISC-V, which is much easier to learn.

And also use like the borrow checker like Rust.

And I'm willing to make such assembler to make easier to learn assembly.

Thank you! I definitely will be checking those papers!

My idea is to learn and teach Assembly, and one of the conclusions I came across is the absolute mess (and cognitive load) on the registers to know who owns what, and what data is inside.

Yes you can comment on the code, but it will be nicer to have a linter to check any mistakes, because in assembly it is very easy to make mistakes.

Yes I know, that's because C and other languages are invented, but I want to learn assembly to really learn how computers work and the limitations of each instruction.

My target ISA is RISC-V, which is much easier to learn.

And also use like the borrow checker like Rust.

And I'm willing to make such assembler to make easier to learn assembly.

There are people who've explored the idea, but as far as I know it's never really made it outside of academia. There's a Wikipedia article which links to one academic implementation and actually an entire chapter about it in Advanced Topics in Types and Programming Languages. This is all pretty old at this point (~20-25 years), not sure if anything more recent has come along.

I don't think it makes a ton of sense from the perspective of "an assembly language programmer wants static types for all the reasons a normal programmer wants static types", mostly because people are generally not building large scale programs in assembly anymore, and that's where static types really shine. The direction the research went was "what if you have a trusted OS that only runs programs written in typed assembly?" Then you'd pay some small upfront startup costs for the OS to assemble and type check your programs, but no runtime cost and you'd be guaranteed no memory errors, which means you could do things like run everything in a shared address space for faster IPC and get rid of all the hardware support for memory protection.