RISC load-store verses x86 Add from memory.
|
From: MitchAlsup on 22 Jun 2010 17:23 On Jun 22, 1:31 pm, n...(a)cam.ac.uk wrote: > I am not going to disagree with your view - merely your > claimed facts. Then we have no issue, here. Mitch
From: nmm1 on 22 Jun 2010 18:08 In article <2010Jun22.201655(a)mips.complang.tuwien.ac.at>, Anton Ertl <anton(a)mips.complang.tuwien.ac.at> wrote: > >>Yes, OF COURSE, you see problems on current systems only when you >>enable significant optimisation - but that's been true of most such >>constraints for at least 50 years - yes, 50. The reason that Java >>Grande flopped, big time, is precisely because Java forbids any >>optimisations that might change the results. Do you REALLY want >>a C with the performance of Java? > >There are many reasons why Java performs as it does; requiring defined >results is only one of them (and I think, a rather minor one), but a >more important reason is that it is a higher-level language. Modern Fortran (95+) is also a higher level language, and outperforms C by a large margin. No banana - try again. >This reason would not apply to a lower-level C, on the contrary: >Programmers could use low-level performance tricks to achieve higher >speed. That was true when I started programming, but hasn't been for many decades. Allowing the compiler to optimise is a FAR better solution, except for extreme computational kernels - and most applications are not dominated by such things. Regards, Nick Maclaren.
From: Andrew Reilly on 22 Jun 2010 18:27 On Tue, 22 Jun 2010 09:02:16 -0700, MitchAlsup wrote: > Why not use the SSE instructions that directly provide saturating > arithmetic? I do use assembly or the equivalent on all specific, identified platforms: there's nothing wrong with the functionality of the hardware, in most cases. It's still desirable to have a reference in "pure C" as a starting point. It seems galling that expressing the algorithm is so difficult to achieve in C. -- Andrew
From: MitchAlsup on 22 Jun 2010 18:37 On Jun 22, 5:27 pm, Andrew Reilly <areilly...(a)bigpond.net.au> wrote: > On Tue, 22 Jun 2010 09:02:16 -0700, MitchAlsup wrote: > > Why not use the SSE instructions that directly provide saturating > > arithmetic? > > I do use assembly or the equivalent on all specific, identified > platforms: there's nothing wrong with the functionality of the hardware, > in most cases. It's still desirable to have a reference in "pure C" as a > starting point. It seems galling that expressing the algorithm is so > difficult to achieve in C. # define sat_add(a,b) (((tmp = (a)+(b)), (tmp > SAT_MAX ? SAT_MAX: (tmp < SAT_MIN ? SAT_MIN : tmp))) Is galling? Note, in this style one can define any bit widths, any signedness, non- symetrical ranges wrt 0, floating point saturated arithmetic,... Using C++ one can wrap thes back to types and override the standard arithmetic operators +,-,... Mitch
From: Andrew Reilly on 22 Jun 2010 18:41
On Tue, 22 Jun 2010 13:34:47 +0100, nmm1 wrote: > A language > specification isn't much use if it specifies only the most trivial > aspects and leaves the rest undefined. A language specification isn't much use if it leaves so much undefined that it doesn't provide semantics to express reasonable algorithms within its nominal remit (i.e., as a low-level systems language, good for building libraries and functionality from the metal up.) I admit that the overflow() idea was daft, but defining operations for signed arithmetic that actually captures what the hardware does doesn't seem unreasonable, or too inimical to optimisation. You certainly haven't made a convincing argument along those lines. Saying "signed integer overflow is just wrong" is unhelpful: it happens, it's what the hardware does, and some reasonable algorithms want to know about it when it happens. Cheers, -- Andrew |