RISC load-store verses x86 Add from memory.
|
From: nedbrek on 19 Jun 2010 08:26 Hello all, "R. Matthew Emerson" <rme(a)clozure.com> wrote in message news:m2d3vocf8a.fsf(a)braegen.myhome.westell.com... > "nedbrek" <nedbrek(a)yahoo.com> writes: > >> But Mitch has it right. Architecture does not matter. > > You guys keep saying this, and maybe for large majority of people it is > even true. > > But I still say that ISA makes a difference. As an example, our Common > Lisp implementation targeted only PowerPC for a long time. Porting it > to x86-64 was a lot of work for a couple of reasons: > > * An x86 assembler and disassembler are complicated and fiddly. Sorry, the fully qualified statment should be "ISA does not make (much of) a difference to performance". It comes up so often, it gets abbreviated a lot. :) It can be a pain for compiler writers (especially ones trying to get the most performance). But y'all are 0% of the market. Ned
From: MitchAlsup on 19 Jun 2010 09:13 On Jun 19, 1:46 am, n...(a)cam.ac.uk wrote: > In article <0922168e-6d6f-4480-85ec-fa5996c33...(a)z10g2000yqb.googlegroups..com>, > > MitchAlsup <MitchAl...(a)aol.com> wrote: > >On Jun 18, 2:28=A0pm, r...(a)clozure.com (R. Matthew Emerson) wrote: > >> "nedbrek" <nedb...(a)yahoo.com> writes: > >> > But Mitch has it right. =A0Architecture does not matter. > > >I think it might be better to say, Instruction sets don't mater, the > >rest of what we call architecture does mater, now and again. > > Er, no. Sorry. I agree that the days when the instruction set made > a big difference to the performance are long gone - but that's only > 20 years gone, not 40. I was refering more to the "Memory Order Model", or "cache coherence" rather than performance. There are parts of the architecture that are not part of the instruction set but are implied by the environment the machine architecture embodies. > However, the same does NOT apply to RAS and usability. Any defects > cause trouble to compilers and debuggers, and one result is higher > software costs, and lower RAS RAS and usability. Also, most weird > properties, dogmas etc. have a tendency to show through. > > A classic example here is the way that integer overflow used to be > (and occasionally still is) trapped - but overflow in multiplication > rarely was. Why? Well, the basic intructions rarely did .... Ahh, yes, the old classic. This was a fall out of the dichotomy of the double width product. Because one had all the bits of the result, the multiply actually did not overflow! {hint: it cannot} The fact that there was no convienent way to determine if the lower half overflowed (or not) was the problem. This is one of those "you can't have it both ways" counter arguments to the "multiply must deliver a double width result" paradigms. But perhaps it is best not to have any integer exceptions. Mitch
From: Robert A Duff on 19 Jun 2010 10:02 "nedbrek" <nedbrek(a)yahoo.com> writes: > It can be a pain for compiler writers (especially ones trying to get the > most performance). But y'all are 0% of the market. I am a compiler writer. It's true that we are 0% of the market, but every computer user is using compilers, directly or indirectly. (Well, except for people using assembly language, which are also 0% of the market, nowadays.) And unnecessary complexities/nonuniformities in an ISA can lead to compiler bugs, which is no good for anyone. Also, the oddities in interrupt handling and so forth that Nick likes to complain about can lead to bugs that affect pretty-much everyone. - Bob
From: nmm1 on 19 Jun 2010 10:37 In article <wcctyozyvbr.fsf(a)shell01.TheWorld.com>, Robert A Duff <bobduff(a)shell01.TheWorld.com> wrote: >"nedbrek" <nedbrek(a)yahoo.com> writes: > >> It can be a pain for compiler writers (especially ones trying to get the >> most performance). But y'all are 0% of the market. > >I am a compiler writer. It's true that we are 0% of the market, >but every computer user is using compilers, directly or >indirectly. (Well, except for people using assembly language, >which are also 0% of the market, nowadays.) And unnecessary >complexities/nonuniformities in an ISA can lead to compiler >bugs, which is no good for anyone. Yes, precisely, speaking as someone who liaises between the users and compiler writers. >Also, the oddities in interrupt handling and so forth that >Nick likes to complain about can lead to bugs that affect >pretty-much everyone. Likes to! Ha! But, yes, especially when the compiler writer has to generate special code to recover from interrupts, which is damn-near untestable at best. Regards, Nick Maclaren.
From: =?ISO-8859-1?Q?Niels_J=F8rgen_Kruse?= on 19 Jun 2010 15:50
Andy 'Krazy' Glew <ag-news(a)patten-glew.net> wrote: > Unfortunately, there are several different types of integer overflow. > E.g. the overflow conditions for each of the following are different > > unsigned + unsigned > signed + signed > signed + unsigned Are you talking about D or some other language that is not C? -- Mvh./Regards, Niels J�rgen Kruse, Vanl�se, Denmark |