BRIEF: the CMO TG mailing list tech-cmo@... has been set up - please add yourselves if interested. I will look through my Inbox for folks who indicated interest and I may add you to the ma

Andy, Will this TG's work include things like cache line zero operations? And what is your thought as far as the interaction or scope between this TG and the J-Ext TG insofar as the J group's work las

I have included ZALLOC (DCBZ) in my current proposal, but I am agnostic as to whether we included in the CMOs. the charter does not say, we can discuss, and then asked the TSC to extend the charter if

It seems like one would desire these routines to be able to use a ZALLOC CMO only when appropriate, e.g. not for a small block and just for the heart of a large block (with the routine appropriately h

I'm having to do this from inside the web site, so I'm not sure if it will work. Yes, I'm the guilty party for the J extension proposal for a follow on to the current FENCE.I to allow for incoherent I

The current thinking for CMOs is toward address regions without regard to cache lines. But of course the full development of a spec is still to be done. Bill

There's considerable thinking in the direction of having the CMOs be address based and not cache line based. If that ends up being so, then a ZALLOC sort of instruction would presumably also handle pa

So I've heard. I can't say I'm a fan in any way of the choice for ranges, though I've mostly resolved myself to the tragic inevitability of things going that way. There will be attendant downstream co

Hi Derek, There's a proposal here. Bill

Hello, everyone: In the PowerPC ISA, the purpose of ZALLOC(DCBZ) is to set all bytes of a cache block which contains the addressed byte to 0. If ZALLOC follows the address based design and its start a

I would expect that if an instruction similar to ZALLOC were defined by the CMO group, and CMOs end up with the address range style, that ZALLOC would only zero the specified bytes. If there were part

I'll probably regret this posting: ZAlloc has three desired behaviors: 1. the line should end up in the cache 2. the line should not have stale data from any other address for security reasons (the ze

I don't think it conflicts, Allen. The reason I don't think it does is that this capability would usually be applied for a reasonably large buffer. It's for the large buffer that we care about #3 in a

I'm not sure I understand your comment "I don't think we should zero full lines". If we aren't transferring the line from memory, and we are overwriting the tag corresponding to the cache line (so it

I didn't state what I meant well at all. Yes, we should zero full lines that are entirely within the address range. I only meant we shouldn't zero full lines which fall partly outside of the address r

I would phrase it a different way: If there is to be an instruction that zeros an address range, taking into account partial lines, that instruction will not be called ZALLOC, but will instead be call

By the way, there is an issues database associated with the GitHub wiki. Feel free to add an issue for this.

Andy, Given what you've said before, I'm surprised you don't want to support destructive options that don't know the cache line size. Bill

I just wanted to chime in with agreement to most of Andy's points: - A "MEMZERO" operation should be left for another day and/or TG. - While we could avoid any standardization of destructive CMO's, th

I want to. I just don't want to do it right now in the CMO group. specifically, I don't want to do partial cache line operations right now in the CMO group. I am open to things like you have proposed,