Hacker News Reader

Comment by tremon | Hacker News Reader

> Processors have a very weak notion of data types

This is absolutely not true, unless you mean to say that processors should somehow support composite (aka C struct) data types as an instruction primitive. Processor operations have to be strongly typed, by definition. For example, these are the data types supported by operations in the modern x86 instruction set (ignoring vector extensions):

- signed and unsigned integers of 8, 16, 32 and 64 bits

- floating-point decimals of 32, 64 and 80 bits (and 128 via sse)

- nul-terminated byte strings

> For example: casting a `float` to an `int` has a very specific definition in C, and that definition involves altering the pattern of bits

I don't understand this example. Casting a float to an int also has a very specific definition in IEEE-754 and is pretty much universally implemented as a hardware instruction. It has been in the x86 family since its inception: https://www.felixcloutier.com/x86/fisttp

View on HN

> Processor operations have to be strongly typed, by definition.

Individual instructions assume the data they operate on is of a particular type, but it doesn't differentiate data types in memory. Here's an example where I forced the C compiler to treat the bit pattern of two floats as integers, then add those values as integers. The result is, of course, absolutely meaningless.

  float dx = 1.0;
  float dy = 1.0;
  int *pix = &dx;
  int *piy = &dy;
  int isum = *pix + *piy;
  float *pdsum = &isum;
  printf("%d\n", isum);
  printf("%f\n", *pdsum);

That's just how processors work, right? Apparently it doesn't have to be that way. From my understanding of the iAPX 432, attempts were made to encode object types in hardware.

Processor instructions are not _strongly typed_. They take bit patterns as input and output new bit patterns.

The bits are untyped, the choice of operation decides how the bits are interpreted. Nothing enforces the type of that result, you can always interpret it as something else. It may not be meaningful. Or it may be, like a fast inverse square root.

Strong typing means that each value has an intrinsic type, and there is no reinterpreting it. What CPUs do is not that, or rather the only types are "_n_-bits" (_n_ a power of 2).

I wholly agree, processors are strongly typed, even if there are holes like using integer instructions on floating-point values in XMM regs, very insightful comment:)

btw a bit of nitpick: to be fair basically no one uses x87 anymore, it's https://www.felixcloutier.com/x86/cvttss2si and friends but yes :)

For "strongly typed" I would expect some type checking.

True for IEE754 floating point operations, which are constrained to valid bit patterns. An operation on an invalid pattern - can happen with uninitialised memory - throws an exception.

Otherwise, no.

What do you mean by invalid patterns? Signalling NaNs? I wouldn't really call those invalid, but also that's only about one in a thousand bit patterns. If it kicks in less than 1% of the time it's not really "type checking".

This is still not type checking, it accepts whenever the bit pattern is a valid for floating point even when it originally was used as another type.

Reply on news.ycombinator.com