Computers with tagged data architecture

[bryanl]

Are there still any advantages to them?

 

[Cerb]

No. Why would you want to have that reduced flexibility, when a regular CPU can do the same thing with an implementation tailored to your environment?

Tagged references/pointers are still commonplace, just not fixed hardware implementations in CPUs. iOS' Obective-C uses them, as a modern example.

 

[SOFTengCOMPelec]

Are there still any advantages to them?

I would imagine that there would be at least several somewhat major drawbacks, to such a scheme, on modern cpu architectures.

Pipe-lining and other speed-up mechanisms, would probably be badly hindered by the fact that they would not know exactly what instruction is next, until the data has been read/examined (as it has the tags in it).
i.e. This would be similar to the problems we already have with branch prediction, and the potential delays, branch instructions can cause.

It may cause security problems, because one of the modern mechanisms is that programs are (potentially) protected from being able to write executable instructions to ram. To minimise the risk of virus's, and similar problems.
But tagged data, would potentially allow rogue programs to mess with the tags, and change the functionality via the data area (of memory), which the virus would be more likely to have access to.

Existing compilers would be generating X86 code (or Arm, or whatever), and would need extensive re-working, to handle the new code generation challenges, of tagged data architecture computers.

Past/present/future programs would have to be at least re-compiled, and maybe re-optimized or even modified, to cope with the new type of cpu. In practice this could take a very long time, to happen.
E.g. How many software packages now use the latest Haswell AVX2 instructions ?

Then the existing customers of cpus/software etc, would have to be persuaded to buy into this new architecture, which would probably be incompatible with most/all software around at the moment, and the newly written software, would only work on these new type of computers (cpu).

Ignoring all the above potentially major problems/issues, I can't easily see how it would offer much benefit to modern cpu architectures.

I get the impression that this was one of the many technologies which was tried out a long time ago (such as in the 60s), and has been mostly long forgotten, these days.
I.e. Along with Drum Disks, Nixie tube displays, Punched cards/tape, Core memory, Floppy disks (especially 8 inch ones), and mini-computers (the big ones from the 1970s and 80s, NOT modern mini-ITX cased computers).

tl;dr

No (not many advantages these days, that I can easily see, except maybe extremely rare/niche application types).

 

[Cerb]

(not many advantages these days, that I can easily see, except maybe extremely rare/niche application types).

Even those can just be done in software, though, and cheaply, without affecting any part of the system that doesn't need it.

FI, let's say you use the top 11 bits for tagging of an aligned 64-bit address. All you need to do to get your address is either AND on a mask and shift left 3, or shift left 11 then right 8. All you need to get your tag is to AND on a mask an barrel shift left, or shift a lot right (or, better, just get the high 2B into another register's low 2B, and right shift it). No branches needed, it should run in parallel/pipelined even on weak in-order CPUs, needs only a handful of instructions (but the best choices will vary by ISA), and using all shifts/movs/loads, needs only 3 registers, which would also be needed, if not more, without the tag implementation.

 

[SOFTengCOMPelec]

Even those can just be done in software, though, and cheaply, without affecting any part of the system that doesn't need it.

Mostly. (Exceptions are so rare, that they can just about be 100% discounted, so I'm NOT disagreeing with you, here)

But if it is done, in an attempt to make an extremely robust/reliable/secure computer system, against software/hardware bugs/design-mistakes/other-issues then it would be best, to implement it in hardware.
i.e. Things like banking computers (you don't want HACKERS messing with them, or them making silly mistakes, with huge amounts of money).
Or space mission stuff.
E.g. One semi-famous space mission, blew up or crashed, despite $500,000,000 or some huge amount of money being spent on it. All because a floating point variable, caused a floating point exception, which was NOT caught, and caused all five computer systems, to eventually dramatically fail.
A test sensor was still connected (or something), which gave silly readings, during the space mission.

I think these days, there would be much better technological possibilities, than this method, which would give better results. Since it would only catch some types of error, and ignore many other possible mistakes.

Example (assuming type checking is done using tagged data)
It would pick-up mistakes, such as a double being plonked into an integer variable (without converting it to an integer, first).

But if an incorrect floating point double (the price, instead of the weight, say) was put in the variable, this system would fail to detect the mistake.

There are so many "virtual" instruct set like things these days (such as JVM, Java Virtual Machine), that software implementation (as you stated), would be really easy.

 

[SOFTengCOMPelec]

Even those can just be done in software, though, and cheaply, without affecting any part of the system that doesn't need it.

FI, let's say you use the top 11 bits for tagging of an aligned 64-bit address. All you need to do to get your address is either AND on a mask and shift left 3, or shift left 11 then right 8. All you need to get your tag is to AND on a mask an barrel shift left, or shift a lot right (or, better, just get the high 2B into another register's low 2B, and right shift it). No branches needed, it should run in parallel/pipelined even on weak in-order CPUs, needs only a handful of instructions (but the best choices will vary by ISA), and using all shifts/movs/loads, needs only 3 registers, which would also be needed, if not more, without the tag implementation.

I think the tagged data method, has been used for a number of things, already, usually in software, rather than hardware. It has just not been talked about, as a topic or type of computer architecture as such.

Because 64 bits of address information is way too big, for quite a while, I sometimes come across stuff, which explains how some of the bit fields, in the 64 bit address are used to give additional information, to software.
I can't remember the details, but I read a lot about it, when I first moved from 32 bit to 64 bit Linux, and was experiencing problems, when compiling older programs, with GCC.

Even 32 bit data, is often way too big, but there is usually no performance benefit, making it 8 bit. It might even be slightly slower.
So some software uses the "spare" bits, to indicate extra stuff.

tl;dr
As a software method, this makes lots of sense, and has probably already been done, with lots of things. But as a hardware architecture, it is probably a bad idea, these days, and should be done by software, as stated by Cerb.

 

[Cerb]

Obj-C's isa was just a very new example that I found, rather than looking at the past. Ever since RISC more or less killed of language-specific CPUs, it's been a common practice in languages that have high run-time overhead, for interpreter loops, reference counting, and that sort of thing.

 

[SOFTengCOMPelec]

I wonder if SIMD could use one of the data fields (or something similar), in the hardware, to allow data tagging, so that greater flexibility on what SIMD does, could take place.

E.g. a bit mask field, with one bit per data element of the SIMD data. 1 means perform the operation on the respective data element, and 0 means do nothing to the respective data element. That might allow SIMD to be more powerful/flexible/useful and hence faster, in real terms.

(I know that the odd SIMD instruction here and there, already does this, such as the gather instruction, I think).

So maybe there is some (hardware) potential to it, after all.

I think the current or slightly older Arm instruction set (I think the later one(s) drop this feature), had something similar to tagging (although it was part of the instruction, rather than the data), which allowed many instructions to additionally perform a condition instruction, ONLY when a certain condition was met, such as carry set, etc.
i.e. The instruction is ONLY activated, when the applicable condition is true, such as "If carry is clear, then perform ADD ..). No actual program counter (branch) adjustment, needs to take place, so the pipline is unaffected (speedy).