What would be the consequence of implementing interfaces as fat pointers ?

[Manu]

On 1 April 2014 18:33, dajones <dajones at hotmail.com> wrote:

>
> "Manu" <turkeyman at gmail.com> wrote in message
> news:mailman.122.1396231817.25518.digitalmars-d at puremagic.com...
> > On 30 March 2014 13:39, Walter Bright <newshound2 at digitalmars.com>
> wrote:
> >>>
> >>> Two pointers structs are passed in register, which is fast. If that
> >>> spill, that
> >>> spill on stack, which is hot, and prefetcher friendly.
> >>>
> >>
> >> That underestimates how precious register real estate is on the x86.
> >
> >
> > This is only a concern when passing args. x86 has huge internal register
> > files and uses aggressive register renaming,
>
> If we could use them that would be great but we cant. We have to store/load
> to memory, and that means aprox 3 cycle latency each way. The cpu cant
> guess
> that we're only saving it for later, it has to do the memory write, and
> even
> with the store to load forwarding mechanism, spilling and reloading is
> expensive.
>

Can you detail this more?

Obviously it must perform the store to maintain memory coherency, but I was
under the impression that the typical implementation would also keep the
value around in a renamed register, and when it pops up again at a later
time, it would use the register directly, rather than load from memory.
The store shouldn't take any significant time since there's no dependency
on the stored value, it should only take as long as issuing the store
instruction; latency is irrelevant, since it's never read back, there's
nothing waiting on it.
Not sure what you mean by 'each way', since stored values shouldn't be read
back if gets the value from a stashed register.

I'm not an expert on the topic, but I read about it some years back, and
haven't given it much thought since.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140401/c84fd4bc/attachment.html>