Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #24248

Re: ARM/Atmel buses, architecture - Naimi

Show all headers | View raw

On Sun, 12 Jun 2016 02:13:35 +0300, Dimiter_Popoff <dp@tgi-sci.com>
wrote:

>On 11.6.2016 ?. 22:51, George Neuner wrote:
>>....
>> Self-modifying code is a serious issue for deep pipelines: the old
>> version of a modified instruction may already have been fetched.
> > ....
>
>Not exactly this but in this line of thought something got me some 15
>years ago when I was dealing with the 5420 in a way I still remember,
>wasted me a day perhaps.
>I had written some self modifying code - not for use in the end device,
>just a one time utility for me. Ran it on the 5420 (was computationally
>intensive and this was my fastest option at the time, then I had made
>a new toolchain for it so I wanted to use it etc.).
>Something pretty simple did not work; the self modifying code seemed
>not to get modified or something. But when I looked with the monitor
>(I had done that for the 5420, too) it was OK. Yet it ran as if it
>was not.
>Turned out I had not read the entire errata sheet. There was something
>about writing to program memory which got never initiated unless a write
>to some data memory took place after it (or something of the sort)...
>So when the monitor trapped it obviously did write to data
>memory - stack etc. - and I saw the correct program memory...
>
>Still remember it, could even locate the source (just found the
>comment "hopefully some write has begun....", did not try to
>get into the details again of course).
>
>Dimiter

It may be that you didn't flush the write(s) ???

AFAIK, starting from the Pentium Pro, all the Intel chips have snooped
data writes and automatically invalidated corresponding code cache
addresses.  They also monitor the code cache and flush the pipeline if
any in-flight instruction is invalidated.

Modern chips snoop the unified L2 cache so cross-core writes can be
seen earlier [before they go all the way to memory].  I would have
thought that the E5420 would be in that class, but some of the old
chips only monitored actual memory writes.

Still, the write wouldn't be seen until it hit at least the L2 cache.
The E5420 had write-back L1, so the writes would have needed to be
flushed explicitly [or you would have needed to wait until the
modified lines were replaced.]


Intel is rather inexplicably nice to self-modifying code: generally
the worst that happens is that it will have poor performance.  Many
other manufacturers are actively hostile: a lot of chips make even
writing _correct_ self-modifying code a challenge.

On most non-Intel chips, in addition to flushing code modifying writes
all the way to memory, you must deliberately invalidate the modified
addresses in the code cache.  On many chips you must also deliberately
invalidate branch predictions.

And then, with some chips, you still must time everything correctly
because the chip will continue to execute already fetched instructions
regardless of whether they have been invalidated in cache.

George

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

ARM/Atmel buses, architecture - Naimi "Veek. M" <vek.m1234@gmail.com> - 2016-06-10 10:59 +0530
  Re: ARM/Atmel buses, architecture - Naimi rickman <gnuarm@gmail.com> - 2016-06-10 01:44 -0400
  Re: ARM/Atmel buses, architecture - Naimi David Brown <david.brown@hesbynett.no> - 2016-06-10 09:13 +0200
    Re: ARM/Atmel buses, architecture - Naimi Tim Wescott <seemywebsite@myfooter.really> - 2016-06-10 12:22 -0500
      Re: ARM/Atmel buses, architecture - Naimi rickman <gnuarm@gmail.com> - 2016-06-10 14:05 -0400
        Re: ARM/Atmel buses, architecture - Naimi Tim Wescott <seemywebsite@myfooter.really> - 2016-06-10 14:06 -0500
        Re: ARM/Atmel buses, architecture - Naimi David Brown <david.brown@hesbynett.no> - 2016-06-11 02:00 +0200
      Re: ARM/Atmel buses, architecture - Naimi George Neuner <gneuner2@comcast.net> - 2016-06-10 21:07 -0400
        Re: ARM/Atmel buses, architecture - Naimi rickman <gnuarm@gmail.com> - 2016-06-10 22:35 -0400
          Re: ARM/Atmel buses, architecture - Naimi Tim Wescott <tim@seemywebsite.com> - 2016-06-10 22:14 -0500
          Re: ARM/Atmel buses, architecture - Naimi Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-11 14:48 +0300
          Re: ARM/Atmel buses, architecture - Naimi George Neuner <gneuner2@comcast.net> - 2016-06-11 15:51 -0400
            Re: ARM/Atmel buses, architecture - Naimi Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-12 02:13 +0300
              Re: ARM/Atmel buses, architecture - Naimi George Neuner <gneuner2@comcast.net> - 2016-06-11 22:40 -0400
                Re: ARM/Atmel buses, architecture - Naimi Dimiter_Popoff <dp@tgi-sci.com> - 2016-06-12 10:22 +0300
                Re: ARM/Atmel buses, architecture - Naimi George Neuner <gneuner2@comcast.net> - 2016-06-13 10:36 -0400
            Re: ARM/Atmel buses, architecture - Naimi Clifford Heath <no.spam@please.net> - 2016-06-12 11:01 +1000
              Re: ARM/Atmel buses, architecture - Naimi George Neuner <gneuner2@comcast.net> - 2016-06-11 23:50 -0400
              Re: ARM/Atmel buses, architecture - Naimi upsidedown@downunder.com - 2016-06-12 10:13 +0300

csiph-web