search for: 18037

...her special features for COBOL), but I’m not aware of any others. --paulr From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Suminda Dharmasena Sent: Saturday, September 07, 2013 2:02 AM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] IEEE 754-2008 | ISO/IEC TR 18037 Hi, Does LLVM support decimal precision numbers supported? Also does it have Fixed point arithmetic? S -- Suminda Sirinath Salpitikorala Dharmasena, B.Sc. Comp. & I.S. (Hon.) Lond., P.G.Dip. Ind. Maths. J'Pura, MIEEE, MACM, CEO Sakrīō! ▣ Address: 6G • 1st Lane • Pagoda Road • Nugegoda 10...

Hi, Does LLVM support decimal precision numbers supported? Also does it have Fixed point arithmetic? S -- Suminda Sirinath Salpitikorala Dharmasena, B.Sc. Comp. & I.S. (Hon.) Lond., P.G.Dip. Ind. Maths. J'Pura, MIEEE, MACM, CEO Sakrīō! ▣ *Address*: 6G • 1st Lane • Pagoda Road • Nugegoda 10250 • Sri Lanka. ▣ *Mobile* : +94-(0)711007945 ▣ *Tele*: +94-(0)11-5 864614 / 5 875614 / 2 825908 ▣

Also Q numbers format can be added for added precision. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130910/a78890c2/attachment.html>

> This will come in handy if you do not have a floating point unit. Also for > speed in some cases. > > To be generic as possible it might be good to have this. The goal isn't really maximum generality, but support for languages that people care about. Currently that's mostly C and C++, with a smattering of features for some others. But features almost never get added

These features can find use in embedded micro controllers and situation where you do not want rounding errors. x86 and ppc sound like Intel and Power PC specific. Of course once introduced some one must maintain it. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130910/8cff2269/attachment.html>

On 9 September 2013 20:21, Suminda Dharmasena <sirinath at sakrio.com> wrote: > These features can find use in embedded micro controllers and situation > where you do not want rounding errors. Not until someone comes up with a language specifying them (or at least a highly suspect variant of C specifying them) they can't. Tim.

Many thanks for getting back. This will come in handy if you do not have a floating point unit. Also for speed in some cases. To be generic as possible it might be good to have this. BTW, in the doc I was reading there was not mention about Quad size numbers, decimal numbers and extended precision numbers. http://llvm.org/docs/LangRef.html#type-system -------------- next part -------------- An

Hi all, Is there any ongoing work in LLVM/Clang to support fixed-point arithmetic as described in ISO/IEC TR 18037 ? It seems that gcc has support for it since 2007 and it would be useful for us to add such support. Just to get an idea if we decide to work on this, how long would it take to get it implemented ? Regards, Ivan

On Wed, Feb 8, 2012 at 3:39 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi all, > > Is there any ongoing work in LLVM/Clang to support fixed-point > arithmetic as described in ISO/IEC TR 18037 ? No. > It seems that gcc has support for it since 2007 and it would be useful > for us to add such support. > Just to get an idea if we decide to work on this, how long would it take > to get it implemented ? It's probably pretty; I don't know precisely what is involved, tho...

...e else interested in fixed-point arithmetic support in clang/llvm? Regards, Sergey On Sat, Aug 3, 2013 at 12:14 AM, Sergey Yakoushkin < sergey.yakoushkin at gmail.com> wrote: > Hi all, > > Were there any further discussion or progress with the fixed point support > (ISO/IEC TR 18037) in the meantime? > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1275.pdf > > Particularly: > 1) named address space type qualifiers (can be nested) > 2) fract/accum data types > 3) sat (saturation) type specifier > > Regards, > Sergey Yakushkin > > > > On...

I have a quad core CPU running Centos5. When I use top, I see that running processes use 245% instead of 100%. If I use gkrellm, I just see one core being used 100%. top: PID USER PR NI VIRT RES SWAP SHR S %CPU %MEM TIME+ COMMAND 18037 thba 31 15 304m 242m 62m 44m R 245.3 4.1 148:58.72 ic Also in the log of some programs I see this strange factor: CPU Seconds = 2632 Wall Clock Seconds = 1090 There are all single threaded programs, so it's not that more cores are being used. [thba at fazant]$ uname -a Linux fa...

...st archives to this thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-November/011385.html. >From there, it is pretty clear that addrspace was introduced specifically as a mechanism for implementing the 'named address space' extensions defined in the Embedded C standard (ISO/IEC TR 18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf). The Embedded C standard gives this overview of the 'named address space' extension: Many embedded processors have multiple distinct banks of memory and require that data be grouped in different banks to achieve maximum per...

...I have a different byte width in p1 over p0 (I know - but we all knew it was coming). All of p0 can be addressed in p1, but the reverse transformation is only sometimes possible as GEPs behave differently on the other side of the cast. This transformation of course breaks that. By my reading of ISO 18037:2006(E), it is required that if one address in p0 can be cast to p1, they all can, but I cannot find any requirements placed on the reverse operation - and further, this is a C standard, not a low-level machine. I realise this may be seen as an abuse of mechanics, but is it really intended that add...

On Mon, Feb 28, 2011 at 4:41 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > The more I think about it, the more I become uncomfortable with the > concept of language-specific address spaces in LLVM.  These are the > main issues I see with language-specific address spaces: ... > Instead of language-specific address spaces, each target should > concentrate on

On Fri, Feb 25, 2011 at 02:55:33PM -0500, Ken Dyck wrote: > The address space mechanism is used by some code generators to > differentiate between physical memory spaces. The PIC16 code generator > uses address spaces 0 and 1 to select between its RAM and ROM spaces. > And X86 uses address space 256 for GS and 257 for FS. In the back end > for a dual-harvard DSP that I've been

...ed and fixed. [mod: You can''t assume that everybody is running rcmd/rexec. There are good, security related, reasons for not running those.... -- REW] -- Jon From mail@mail.redhat.com dutecai.et.tudelft.nl [130.161.38.38]) (dutecai.et.tudelft.nl rosie.et.tudelft.nl by Received: (qmail 18037 invoked from network); 27 Nov 1996 22:38:05 -0000 Received: from softdnserror (HELO rosie.et.tudelft.nl) (130.161.127.248) by mail2.redhat.com with SMTP; 27 Nov 1996 22:38:03 -0000 Received: from cave.et.tudelft.nl (cave.et.tudelft.nl [130.161.127.241]) by rosie.et.tudelft.nl (8.7.4/8.7.3) with E...