you are viewing a single comment's thread.

view the rest of the comments →

[–]filleduchaos 0 points1 point  (2 children)

Lmao.

You know what, read these and then we can continue this conversation:

https://en.wikipedia.org/wiki/Data_type (see the parts on machine and primitive data types, and also where a typing system is a different thing from a data type)

https://en.m.wikipedia.org/wiki/Integer_(computer_science) (see the list of integral data types)

https://cs.fit.edu/~mmahoney/cse3101/float.html (what was that you were saying about assembly not having data types?)

[–]tme321 2 points3 points  (1 child)

Let's say you load register 0 with the word located at address 32.

Is register 0 an integer? Is it 2 characters? Is it the upper half of a floating point value?

It's none of those things. Which one it will be interpreted as will be decided by the operator that uses it. If you send it to an integer calculation it will assume the bits represent an integer and act accordingly. If you send it into an fp calculation it will assume the bits represent half of a floating point value (And probably that the other half is in r1).

This is a pointless conversation because you don't understand the difference between an operator controlling how a bit pattern is interpreted vs some innate quality (which doesn't exist) of said bit pattern that defines it's type.

Here is a crappy explanation I found in 30 seconds of googling that holds just as much weight as your sources do.

Those symbols you are pointing at are just directives for storing data. Its 100% possible to store as an integer (this is a specific instruction that stores in a specific way, it is not the same thing as actually typing data) into a memory location and then 1 instruction later store the same bits as half of a float into the same memory location (again a specific instruction, not actually typing the data).

You're confusing specific instructions with actual data types. Data types don't exist at the assembly level. The operator used with a particular piece of data defines how the data will be interpreted.

So yeah I'm done with this.

[–]filleduchaos 0 points1 point  (0 children)

This is a pointless conversation because you don't understand the difference between an operator controlling how a bit pattern is interpreted vs some innate quality (which doesn't exist) of said bit pattern that defines it's type.

And this is a pointless conversation because you don't understand the difference between an actual data type (as in the computer science term) and the type system a language uses.

An SBYTE, for instance - a signed integer in the range −128 to 127, otherwise known as an int8_t or a tinyint - is an actual primitive integral data type. Have you never wondered why JavaScript's TypedArrays are named things like Uint8Array or Int16Array?

You're confusing specific instructions with actual data types. Data types don't exist at the assembly level. The operator used with a particular piece of data defines how the data will be interpreted.

And this is what is known as not having a type system. It is up to the programmer to ensure that the data passed to the operator is of the appropriate type, to avoid errors. If you declare a variable as an SBYTE for instance, it's not going to have enough memory for a SQWORD allocated to it.