dmcq (dmcq.delete@this.fano.co.uk) on March 22, 2021 4:33 am wrote:
> rwessel (rwessel.delete@this.yahoo.com) on March 21, 2021 10:47 pm wrote:
> > anon2 (anon.delete@this.anon.com) on March 21, 2021 7:08 pm wrote:
> > > rwessel (rwessel.delete@this.yahoo.com) on March 21, 2021 5:05 am wrote:
> > > > anon2 (anon.delete@this.anon.com) on March 21, 2021 4:52 am wrote:
> > > > > anon (anon.delete@this.anon.com) on March 21, 2021 3:22 am wrote:
> > > > > > Hugo Décharnes (hdecharn.delete@this.outlook.fr) on March 20, 2021 7:34 am wrote:
> > > > > > > Having programs delivered in annotated, intermediate representation (IR) would be great. When compiled
> > > > > > > to a specific ISA, removing instructions is impossible, while adding new ones does not benefit the already
> > > > > > > compiled programs.
> > > > > >
> > > > > > I think you are a bit late to the party. Software has been distributed using IR and then
> > > > > > compiled/JITed on the target machine for over two decades now... just look at Java and
> > > > > > .NET applications. And even if you counter that it's something different as these target
> > > > > > a virtual machine rather than the "real" hardware, here are some other examples:
> > > > > >
> > > > > > - Compiled GPU shaders on virtually every platform
> > > > > > - Apple has been distributing iOS software as LLVM bytecode since 2015
> > > > > > - WASM
> > > > >
> > > > > Over 3 decades with OS/400.
> > > >
> > > >
> > > > S/38 shipped in 1978.
> > >
> > > Ah true, so 4 decades now. As far as I know, they switched to a quite radically different
> > > architecture (PowerPC) albeit with some added hardware features to improve performance
> > > of the result (although these may have been less about the shipped intermediate code in
> > > general, and more about the specific single address space nature of the system.
> >
> >
> > S/38-AS/400-IBM i changed the native ISA several times in the S/38 and early
> > AS/400 eras, until they settled on PPC with the model 400s, IIRC.
> >
> > The MI code continued to run through all that.
> >
> > The extensions to PPC were fairly modest. Basically a tag
> > bit got added to each word (4/8/16 bytes, depending
> > on model), and stored in the ECC bits. Normal stores would clear the tag bits. But in "Tags Active" mode,
> > STQ would copy the tag bit from a bit in XER. That could then be checked at load time (LQ would load the
> > tag bit into the bit in XER in TA mode, and you could test that), and thus prevent pointers or capabilities
> > from being used if they were modified. A few other instructions and small operational changes were added,
> > as well as a funky system call instruction, if you enabled "TA" mode in an MSR.
>
> I saw another project which was considering storing a tag bit in the ECC as an alternative
> to having it separate, I just thought WTF about it but didn't enquire further but obviously
> they must have a way of making it work. I just don't see how it can be done without compromising
> the whole ECC system - have you a link to something about it thanks?


Most ECC schemes have some extra space. For example, tradition SECDED on 64 bit words has about .83 bits "extra" space relative to what's required for single bit correction and double bit detection. If you applied traditional SECDED to 128 bit memory words, you'd have a full seven bits unused (plus a partial bit in the 9 bit ECC).

Of course in the SECDED/128-bit case you could do better than SECDEC by actually using those extra bits - single error correction and 8 bit detection would be possible. Obviously you could instead use one of those bits for the tag, and still get 7 bit detection.

Many of the more sophisticated schemes (chip-kill and the like) have even greater overhead.

But stuffing some sort of tag into the ECC inherently involves weakening the (potential) level of protection. Exactly how much weaker is acceptable is going to depend on the application. You could, for example, spread your tags over two 64/72 memory words (with normal-ish SECDED), where you have about 1.6 bits to play with without weakening SECDED, or decide that single error correction, (most) double error detection is good enough.

Really efficiently using those fractional bits can be quite a bit of work, though, so it's often easier just to have enough "free" bits that you can uses in a straight-forward way. For example, an implementation could just make the physical word a bit wider - a 73 bit physical memory word would allow you to implement either SECTED, or SECDED with a tag bit. Weird memory widths were more common in the older days, though, now almost everything is built out of standard DIMMs (I believe the pre-PPC S/38 and AS/400s took that route).

While not directly applicable to general memory tagging (where you need to be able to tag any memory word, containing any value), the presence of "code violations" is also potentially useful. For example, with 64/72 memory and SECDED, you could store 2**64 "normal" values, or 2**63.83 "special" (tagged) values. CVs are common in communications, where they're used for in-band signaling, frame delimiters and such.

I don't know exactly what IBM did with PPC AS, but the architecture requires one tag bit on each 128 bit memory word, but doesn't define how that's physically stored.