From: Nick Maclaren on

In article <apSdnSC3XseEd6nYnZ2dnUVZ_sydnZ2d(a)comcast.com>,
Joe Seigh <jseigh_01(a)xemaps.com> writes:
|> >
|> > Much of the load/store atomicity is unspecified, especially with regard
|> > to multiple cores and data objects which need a lower alignment than
|> > their size. That is a common source of problem.
|>
|> Case in point, the complete and utter lack of a clear and unambiguous
|> publically documented memory model for Intel architecture. We've
|> had comments from Andy Glew to that effect here on c.a.

Precisely. I am glad that someone seems to understand the issue.


Regards,
Nick Maclaren.
From: Nick Maclaren on

In article <4534e9db$0$1354$834e42db(a)reader.greatnowhere.com>,
"Eric P." <eric_pattison(a)sympaticoREMOVE.ca> writes:
|>
|> That is why you cannot provide examples.

I did. I provided two that apply to all of x86, IA64, MIPS, SPARC
(probably even restricted to v9, but I haven't checked) and zArch.
I have encountered both of them (including differences between CPU
implementations) on all of those.

Go and read those architectures, CAREFULLY, and you will see that.
Also, if you had relevant experience, you will know that there have
been quite a lot of changes in those areas. Look at the Linux and
other kernels for evidence.


Regards,
Nick Maclaren.
From: Eric P. on
Nick Maclaren wrote:
>
> In article <4534e9db$0$1354$834e42db(a)reader.greatnowhere.com>,
> "Eric P." <eric_pattison(a)sympaticoREMOVE.ca> writes:
> |>
> |> That is why you cannot provide examples.
>
> I did. I provided two that apply to all of x86, IA64, MIPS, SPARC
> (probably even restricted to v9, but I haven't checked) and zArch.
> I have encountered both of them (including differences between CPU
> implementations) on all of those.

No, you said:

> In all cases, look at the areas I gave. A couple of simple examples:
>
> The set of cases where floating-point is handled by emulation is
> unspecified, and (clearly) the handler has to handle such cases.
> This also applies to integer multiplication and division on some
> architectures.
>
> Much of the load/store atomicity is unspecified, especially with regard
> to multiple cores and data objects which need a lower alignment than
> their size. That is a common source of problem.

I see, so your point is the totally vacuous and useless observation
that some processors have some problems.

Some asteroids hit the earth. There, see how helpful that was?

> Go and read those architectures, CAREFULLY, and you will see that.
> Also, if you had relevant experience, you will know that there have
> been quite a lot of changes in those areas. Look at the Linux and
> other kernels for evidence.

If you had even one concrete example, you would have provided it.
Those with the relevant experience deal with specific issues on
specific processors and don't listen to people whose sole contibution
is vague warnings that the sky might someday fall. So to the extent
that I have, in the past, had to sit through meetings while such
persons blither on, I also have 'relevant experience'.

Eric


From: Eric P. on
Nick Maclaren wrote:
>
> In article <apSdnSC3XseEd6nYnZ2dnUVZ_sydnZ2d(a)comcast.com>,
> Joe Seigh <jseigh_01(a)xemaps.com> writes:
> |> >
> |> > Much of the load/store atomicity is unspecified, especially with regard
> |> > to multiple cores and data objects which need a lower alignment than
> |> > their size. That is a common source of problem.
> |>
> |> Case in point, the complete and utter lack of a clear and unambiguous
> |> publically documented memory model for Intel architecture. We've
> |> had comments from Andy Glew to that effect here on c.a.
>
> Precisely. I am glad that someone seems to understand the issue.

No. Apparently you don't understand your own point (or maybe are
trying to change it on the fly again).

The fact that the specs are unclear and ambiguous does not
support your assertion that on all systems a correctly implemented
micro architecture has visible implications that require code changes
to compensate for.

What are those code changes, on which Intel x86 makes and models?

Eric

From: kenney on
In article <eh2l0a$t90$1(a)gemini.csx.cam.ac.uk>,
nmm1(a)cus.cam.ac.uk (Nick Maclaren) wrote:

> Much of the load/store atomicity is unspecified, especially
> with regard to multiple cores and data objects which need a
> lower alignment than their size. That is a common source of
> problem.

Are you talking solely about factors that affect program
optimisation? I ask this because most high level languages
isolate the programmer from the architecture anyway. Come to that
so do operating systems with the HAL. Presumably this is most
important for compiler writers.

Ken Young