RISC load-store verses x86 Add from memory.
|
From: Andrew Reilly on 22 Jun 2010 05:29 On Tue, 22 Jun 2010 09:55:25 +0100, nmm1 wrote: > That is the excuse for the WG14 wild-eyes who want to perpetrate TR > 18037. While there is nothing wrong with adding saturating arithmetic, > fixed point, or both - in theory - C99's arithmetic model is already > ghastly almost beyond belief, and that complicates it by a MASSIVE > factor. And that's ignoring the other strand to that TR. I don't need fixed point arithmetic or new types, I just want a "C" that defines sane behavior for all of the operations on the fixed-width, 2's compliment integers that exist on essentially all processors made today. Frankly, something like LLVM's assembly language hiding under a "sufficiently expressive" macro language would just about do the job. Particularly since the llvm assembler seems to define an escape syntax that provides access to the native instruction set of whatever it's running on. Everything else could be synthesized. Cheers, -- Andrew
From: Terje Mathisen "terje.mathisen at on 22 Jun 2010 06:02 Andrew Reilly wrote: > On Sun, 20 Jun 2010 10:39:15 +0100, nmm1 wrote: >> You shouldn't >> write code that overflows in C or Fortran. End of story. Sorry, but >> that is the situation, both de jure and de facto. > > Unfortunately, that's not an answer I can make any use of. Signal > processing with fixed point arithmetic generally requires maximising SNR > (left-aligning values to the greatest extent possible) in algorithms that > often have unlikely extreme-range conditions. Generally, it is > preferable to clip than wrap-around, which is why all processors designed > for the purpose have saturating signed addition modes (or in-register > headroom and saturating store modes). While that makes for neat per- This is probably the fastest pure C alternative: I.e. use double-wide register variables. OTOH, if you're doing something like FFT or DCT processing you still need to store back results after every butterfly, so you would have to use a double-wide working array. > processor optimised code, it's nice to have a vanilla-C fallback that > does the right thing, as a reference. That is now considerably uglier > than it needs to be/used to be. Do you really need to be line-for-line compatible, or can you wrap larger amounts of code into standalone blocks which work with enough headroom to avoid the need for saturation, then saturate only at the end of the block? > > Unfortunately-II: C is essentially the only language that one can count > on being available, in some form. I don't fancy joining the increasingly- > long line of folk who have created their own "fixed" C, but it seems that > that's not entirely outside the realms of necessity, at some stage. :-) Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
From: Terje Mathisen "terje.mathisen at on 22 Jun 2010 06:06 Andrew Reilly wrote: > I don't need fixed point arithmetic or new types, I just want a "C" that > defines sane behavior for all of the operations on the fixed-width, 2's > compliment integers that exist on essentially all processors made today. Hear, hear. > > Frankly, something like LLVM's assembly language hiding under a > "sufficiently expressive" macro language would just about do the job. > Particularly since the llvm assembler seems to define an escape syntax > that provides access to the native instruction set of whatever it's > running on. Everything else could be synthesized. You would have loved Watcom's compilers! Watcom allowed you to define pretty much any operation yourself, in the form of inline macro operations where you specified to the compiler where the inputs needed to be, where the result would end up and exactly which registers/parts of memory would be modified. This basically meant that you could extend the built-in range of basic operations while still getting pretty well-optimized code. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
From: nedbrek on 22 Jun 2010 07:21 Hello all, "Terje Mathisen" <"terje.mathisen at tmsw.no"> wrote in message news:so66f7-hlq2.ln1(a)ntp.tmsw.no... > MitchAlsup wrote: >> The one thing I did take away from the presentation mentioned above, >> is that there were way too many constants in registers in the original >> incarnation. This is one of those things that happens when lots of >> registers are available (essentially) for free. For machines like >> IA32, one should essentially migrate the registerized data into the >> data cache, and then decorate the 6 remaining registers with data >> actively being manipulated, preallocating very few for LISP >> environmental data. Yes, don't expect to come off of hacking PPC to x86 and being able to use all the same tricks. Every arch has its own tricks. > I agree, the key issues seemed to be large number of immediate values > (easily loaded from L1 when needed, particularly in the load-op > instruction format) and all the various pointers to LISP-specific data > areas. > > In a multi-threaded implementation you need to communicate via memory > variables anyway, in which case the most important consideration is to > make sure all shared data structures that must be updated by multiple > threads are located in separate cache lines. Make sure writable locations are on separate cache lines (64 bytes start to start) from the read-only values. That will prevent a lot of communication misses. If possible, place every writable location on its own cache line (unless writes are grouped - a mutex bool and its protected value can [and should] be on the same line). Ned
From: nmm1 on 22 Jun 2010 06:33
In article <88be3vFcceU2(a)mid.individual.net>, Andrew Reilly <areilly---(a)bigpond.net.au> wrote: >On Tue, 22 Jun 2010 09:55:25 +0100, nmm1 wrote: > >> That is the excuse for the WG14 wild-eyes who want to perpetrate TR >> 18037. While there is nothing wrong with adding saturating arithmetic, >> fixed point, or both - in theory - C99's arithmetic model is already >> ghastly almost beyond belief, and that complicates it by a MASSIVE >> factor. And that's ignoring the other strand to that TR. > >I don't need fixed point arithmetic or new types, I just want a "C" that >defines sane behavior for all of the operations on the fixed-width, 2's >compliment integers that exist on essentially all processors made today. Ah, so you want the compiler to trap overflow, diagnose where it happened and terminate your program. LIA-1 specifies that as a (perhaps the) preferred mode. Regards, Nick Maclaren. |