4 ms·

TALs are not what I am referring to here. I am arguing that assembly is already typed and does not need extra annotation to be typed. TALs are also solving an

TALs are not what I am referring to here. I am arguing that assembly is already typed and does not need extra annotation to be typed. TALs are also solving an entirely different problem.

genxy 2mo ago
The technique is good, and compilers that interact with assembly should do this, but as you outline, they basically just shove blobs of text around and hope for the best. I didn't say you were referring to TALs. Yours is a syntax level check, not type checking of the program in the normative sense. It might be more accurate refer to your technique as an "instruction signature", rather than a type. I would argue that that are complementary and not entirely different. I thought it would be interesting for folks.
questionableans 2mo ago
But a language being “typed” doesn’t tell us anything useful. Untyped languages are typed too: they’re uni-typed (every expression is an expression). I think you do your analysis a disservice by focusing on “is assembly language typed?” as the top line question. The more interesting question you examine is what do the type constraints in inline asm offer, and how do they interact with the host language’s type system?
- gingerBill 2mo ago
  I know that "untyped" means a single-type, but assembly operands have multiple different kinds of types (as I state in the article). What makes it really interesting is what you can know about each instruction and what it does (what operands it excepts, what it clobbers, what side-effects its has, etc). 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.
  - questionableans 2mo ago
    Yes, and your second paragraph above is the interesting part that I would want the reader to focus on, starting from the title.
  - jkhdigital 1mo ago
    In other words, the type of an assembly instruction specifies its effects and coeffects. This is an active research area—describing effects and coeffects in the type system, and discharging handler/provider obligations at the compiler level. I suspect the main reason someone might quibble over the “assembly is typed” assertion is that many programmers have a rather narrow view of type systems, heavily skewed by OOP patterns.
    - gingerBill 1mo ago
      That's pretty much the quibble. Most people's narrow view of type system. 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".

TALs are not what I am referring to here. I am arguing that assembly is already typed and does not need extra annotation to be typed. TALs are also solving an entirely different problem.

genxy 2mo ago

The technique is good, and compilers that interact with assembly should do this, but as you outline, they basically just shove blobs of text around and hope for the best. I didn't say you were referring to TALs. Yours is a syntax level check, not type checking of the program in the normative sense. It might be more accurate refer to your technique as an "instruction signature", rather than a type. I would argue that that are complementary and not entirely different. I thought it would be interesting for folks.

questionableans 2mo ago

But a language being “typed” doesn’t tell us anything useful. Untyped languages are typed too: they’re uni-typed (every expression is an expression). I think you do your analysis a disservice by focusing on “is assembly language typed?” as the top line question. The more interesting question you examine is what do the type constraints in inline asm offer, and how do they interact with the host language’s type system?

gingerBill 2mo ago
I know that "untyped" means a single-type, but assembly operands have multiple different kinds of types (as I state in the article). What makes it really interesting is what you can know about each instruction and what it does (what operands it excepts, what it clobbers, what side-effects its has, etc). 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.
- questionableans 2mo ago
  Yes, and your second paragraph above is the interesting part that I would want the reader to focus on, starting from the title.
- jkhdigital 1mo ago
  In other words, the type of an assembly instruction specifies its effects and coeffects. This is an active research area—describing effects and coeffects in the type system, and discharging handler/provider obligations at the compiler level. I suspect the main reason someone might quibble over the “assembly is typed” assertion is that many programmers have a rather narrow view of type systems, heavily skewed by OOP patterns.
  - gingerBill 1mo ago
    That's pretty much the quibble. Most people's narrow view of type system. 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".