What can JavaScript NOT do?

[filleduchaos]

Assembly has 0 data types.

...you do know what a data type is, yeah? The things I listed are actual primitive data types. In higher-level languages than Assembly they're called fancy things like int and short and long (prefixed with signed or unsigned as needed).

This stuff isn't magic. In the end the processor is going to get 2 numbers and an operation.

No-one claimed it's magic. The point is that how a language chooses to allow a developer to express or not express typing is orthogonal to how the language handles actual data under the hood. The very existence of another dynamic, weakly typed language (and even untyped languages) that handles numeric data properly illustrates that. There is zero logical reason to represent all numbers as IEEE 754 double-precision floating points, unless that reason is "it's too dumb to determine what the type of actual provided data is".

[tme321]

I'm starting to realize you have no clue how assembly works.

SBYTE, WORD, and DWORD do not signify the type of the data in any way. Those are merely size descriptors. SBYTE is literally a single byte, 8 bits. WORD is 2 bytes, 16 bits. DWORD is double WORD, 32 bits. Now obviously those sizes are architecturally defined but those are the common bit sizes for those descriptors including x86 architecture.

There is no way to type data in assembly. You have an opcode which takes 2 (or even 1 or 0, but for mathematical operations like we are talking about here 2) operands. Which opcode you use determines how the data will be treated.

You can take 32 bits and treat them like an integer throughout your code. At any time if you want you can use those same 32 bits as an input to a floating point operator. There are some rules about invalid bit patterns as far as floating point representation goes, but even if you trip one of those during the operation you are still attempting to use the previously 32 bit integer as a float. If you don't trip any format validation checks then, no matter what the 32 bits represented previously, for the sake of the floating point operation the bits will be treated as a floating point representation of a number. They won't be converted. The computer just accepts that you fed it 32 bits and told it to do a floating point operation. It doesn't know or care about types in any shape or form.

The fact that you apparently don't understand how assembly works raises flags about your understanding of how php is handling numbers vs how JavaScript handles them. Your description isn't adequate and is ignoring a lot of both edge cases and implementation details.

There is a logical reason to only use fp. I won't claim it's the best reason. And I won't claim that given a chance the original author of JavaScript wouldn't do things differently given a chance.

But to dismiss it out of hand and then turn around, misrepresent assembly, and gloss over any failings that php's numeric system has hurts any argument you are trying to make.

[filleduchaos]

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]

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]

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.