I think a challenge to me for typing assembly, unless you’re doing old-school C style minimally-useful types, is that assembly types tend to be both more ad hoc and more transient than types in higher level languages, because these types come from the intersection of the problem domain and the way of expressing the solution, instead of just from the problem domain. In C++ I might have a type for “aircraft velocity in mm/s”, but in assembly I might have that type on one line, and then go to velocity in 2x mm/s the next line to save a renormalization; or have types for various state flags, but have them pack differently into a word in different places in the code. This is all expressible, but I think it would make me favor a more implicit typing with a heavier emphasis on deduction, just to minimize the description of types that exist but are not in themselves interesting.
Just thinking about an aircraft's velocity as a specific type, rather than a vector with three floats, has my mind whirling. I can imagine a lot of terrifying things I wish I didn't think could be added later to that struct in some avionics system. What would you need a type for that for? Am I thinking too high level, where this type might include its own getters and function calls?
Think of types more as physical units to check your calculation. The position on a chess board and on a checker board are both 2d integer vectors but you might or might not want them able to be summed together, the same way that 5 liters and 5 grams are both real numbers but should not be summed.
So if your algorithm counts apples and counts pears, those wouldn't both have the type "integer". Far from it. They would have the types "number of apples" and "number of pears".
See the other replies — think physical units. An aircraft velocity is a three-vector, but not all three vectors are aircraft velocity. There are probably many different aircraft velocity types, but taking a typical one (NED alignment, mm/s scaling, some particular precision), the type is the set of three vectors that can, for example, be meaningfully added to each other. It makes sense to add two aircraft velocities; it does not make sense to add an aircraft velocity and a pixel color (another three vector), so they are observably different types.
Any 3x3 vec (position 3, velocity 3, rotation 3) that would be more than that, a class specific to an aircraft, would be something much more. It would have position and velocity, and then it would have functions (getters, setters, or prediction functions). Something about the way OP said this was "a type" makes me very suspicious, because those raw values ought to be what you get when you poll the xvxrx ... of the type. If you're getting some sort of interpolation from that, it would obviously need to be from something which extended the type of an object in a certain position and attitude.
The reason I'm saying this is that this is exactly where terrible feedback loops occur, when a type may return an altered version of its basic data when trying to access the basic data.
If it's a type which has an underlying 3x3 vec and this type is specific to the aircraft so it has a bunch of overriding functions to operate on that data, that's fine, that's called a computer program. Not a specific type extending a vector.
