Assembly is typed. The types are machine words and usually floating point types are also available. Basically, the machine types are the types of data that the register files can hold.

That's not a useful notion of type. If I cannot tell statically by inspecting a register name nor dynamically by inspecting a bit pattern whether a given register holds a pointer or an integer or a floating-point value, that's pretty much the definition of "untyped".

Dynamic type testing or introspection is not an essential feature of type systems. The fact is, your computing machine is typed. You can not deference a floating point register as an address, for instance.

> Dynamic type testing or introspection is not an essential feature of type systems.

I didn't say so. An essential feature of type systems is being able to determine the types of (many) values, statically or dynamically.

> You can not deference a floating point register as an address, for instance.

So you'd agree that architectures that don't make a distinction between integer and floating point registers are untyped? But sure, call this a type system if you must. It's just a very very weak one, so weak as to be almost entirely useless. (And the reason floating point registers are often separate from integer registers is not to provide this kind of "type safety", it's due to history and architecture.)

> It's just a very very weak one, so weak as to be almost entirely useless.

Weak and strong aren't meaningful terms. A machine ISA might have an inexpressive type system and/or an unsound type system (because it conflates addresses and integers).

> And the reason floating point registers are often separate from integer registers is not to provide this kind of "type safety", it's due to history and architecture.

No, the reason is performance. And we get performance by making statically known distinctions between datatypes, which is what the original poster asked about.

Intermingling the integer and floating point circuitry so they access the same register file would never improve performance over keeping them separate. You'd need longer wires to place them both near the same register files to minimize signal latency, an the added signal delay alone ensures lower performance.

>> It's for architectural reasons.

> No, it's for architectural reasons.

You win, I guess?

I'm not sure who you're quoting, but I never even used the word "architecture". I don't even know what that's supposed to mean.

You try to explain CPU architecture to me, then claim you don't know what CPU architecture is? OK, maybe you don't win, in any case I'll stop here.

"Architectural reasons" is nonsense. "Architecture" isn't a set of reasons justifying anything, rather it's the other way around: we design architecture for specific reasons. Your claims that we do things for "architectural reasons" don't have any clear meaning. I said the actual reasons are performance. I don't think I'm the one being unclear.

Yep. You can, of course, make a similar argument for Scheme. But you don't get a very interesting type system out of it.

Perhaps I should have written "... nontrivially statically typed."

Sure, but to bring it back to the original question, the fact that you can trivially distinguish floating point from word types already means statically typed languages are easier to optimize than dynamically typed languages for numerical programs.

And there are all sorts of optimizations like this that simply aren't available to dynamically typed languages. Tracing JIT can only take you so far.

OK, but that wasn't the original question.

(There are also all sorts of optimizations that can't be done statically, so I guess there's that.)

The original question asked whether static typing is needed when maximal performance is required. If we understand "maximal" to mean literally, "no more performance can possibly be squeezed out", then it simply is. Static typing might not be sufficient for this case, but it is necessary.

I think those few, crucial pieces of hand-written assembly language one sees from time to time disagree with you. (Modulo your observation that assembly languages are trivially statically typed.)

> I think those few, crucial pieces of hand-written assembly language one sees from time to time disagree with you.

I still don't think so. For example, plenty of silicon is spent on branch predictors simply because addresses and integers aren't distinguished, in general, thus permitting more expressive but costlier code.

Execution would be much faster if integers and addresses were forced to be distinct. Static typing pretty much always improves performance.