From mass3mass at gmail.com Fri Aug 5 00:14:49 2011 From: mass3mass at gmail.com (MAS .) Date: Fri, 5 Aug 2011 12:44:49 +0530 Subject: [Xorp-hackers] Little Help Message-ID: Hi All, I am new user at XORP, I want to do may masters project in XORP developement. But I dont have much experience of routing platforms, I have coding experience in net-snmp. Can you please help me for finding out what potential development can be done in 6 months time. How can I contribute to open source community. Also please help me about How to start. Thanks to all in advance. cheers to open-source community !!! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110805/32f574b7/attachment.html From greearb at candelatech.com Fri Aug 5 11:25:46 2011 From: greearb at candelatech.com (Ben Greear) Date: Fri, 05 Aug 2011 11:25:46 -0700 Subject: [Xorp-hackers] Little Help In-Reply-To: References: Message-ID: <4E3C35AA.8000808@candelatech.com> On 08/05/2011 12:14 AM, MAS . wrote: > Hi All, > > I am new user at XORP, I want to do may masters project in XORP > developement. But I dont have much experience of routing platforms, I > have coding experience in net-snmp. Can you please help me for finding > out what potential development can be done in 6 months time. How can I > contribute to open source community. Also please help me about How to > start. The xorp wiki can always use improvements: http://xorp.run.montefiore.ulg.ac.be/start You could also look at the bug list and see if anything looked interesting: http://www.xorp.org/bugzilla/ Using it and reporting bugs and helping answer other people's questions is all useful stuff. Some folks are interested in adding PIM-DM, so if you wanted some more serious programming experience, you might team up with them to implement that. Thanks, Ben > > Thanks to all in advance. > > cheers to open-source community !!! > > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- Ben Greear Candela Technologies Inc http://www.candelatech.com From 43026437 at qq.com Fri Aug 5 18:48:06 2011 From: 43026437 at qq.com (=?ISO-8859-1?B?d3hoNTg1?=) Date: Sat, 6 Aug 2011 09:48:06 +0800 Subject: [Xorp-hackers] vrrp is not work on linux. Message-ID: dear Ben Greear : vrrp is not work on linux. connect: xorp router==============switch a.f #show -all protocols { vrrp { interface eth1 { vif eth1 { vrid 1 { priority: 2 interval: 1 preempt: true ip 192.168.1.1 { prefix-length: 24 } disable: false } } } interface eth2 { vif eth2 { vrid 1 { priority: 100 interval: 1 preempt: true ip 192.168.1.1 { prefix-length: 24 } disable: false } } } } } [edit] # quit a.f>show version Version 1.8.3 a.f>show vrrp Interface eth1 Vif eth1 VRID 1 State initialize Master IP 0.0.0.0 Interface eth2 Vif eth2 VRID 1 State initialize Master IP 0.0.0.0 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110806/7a49f747/attachment.html From 43026437 at qq.com Fri Aug 5 22:44:02 2011 From: 43026437 at qq.com (=?ISO-8859-1?B?d3hoNTg1?=) Date: Sat, 6 Aug 2011 13:44:02 +0800 Subject: [Xorp-hackers] xorp vrrp work well Message-ID: xorp router work well with cisco router,on freebsd 7.3 connect: cisco router-------switch------xorp router cisco router config: #show run ...... interface FastEthernet0/0 ip address 192.168.3.1 255.255.255.252 duplex auto speed 100 ! interface FastEthernet0/1 ip address 192.168.1.5 255.255.255.0 duplex auto speed 100 vrrp 1 ip 192.168.1.3 ...... xorp router config admin at r.d# show protocols { vrrp { interface fxp0 { vif fxp0 { vrid 1 { priority: 150 ip 192.168.1.3 { } } } } } } interfaces { interface fxp0 { vif fxp0 { address 192.168.1.4 { prefix-length: 24 } } } interface fxp1 { vif fxp1 { address 192.168.5.1 { prefix-length: 24 } } } } [edit] admin at r.d> show vrrp Interface fxp0 Vif fxp0 VRID 1 State master Master IP 192.168.1.3 admin at r.d> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110806/8e4ae315/attachment.html From 43026437 at qq.com Sat Aug 6 18:01:43 2011 From: 43026437 at qq.com (=?ISO-8859-1?B?d3hoNTg1?=) Date: Sun, 7 Aug 2011 09:01:43 +0800 Subject: [Xorp-hackers] VRRP is no work, when one xorp router connect to switch with two line. Message-ID: VRRP is no work,when one xorp router connect to switch with two line.but two xorp router connect to switch,it is work well xorp router=============switch (it is not work) xorp router--------------------switch------------------xorp router (it is work well) xorp router--------------------switch-----------------cisco router (it is work well) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110807/a32f786b/attachment.html From noreply at github.com Mon Aug 8 19:27:17 2011 From: noreply at github.com (noreply at github.com) Date: Mon, 8 Aug 2011 19:27:17 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] c31e1d: Update win32_pkg script to build as well. Message-ID: <20110809022717.BD16C4259A@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: c31e1d1c7f8bc1db1a36eba4a26c0c4c50b4fe52 https://github.com/greearb/xorp.ct/commit/c31e1d1c7f8bc1db1a36eba4a26c0c4c50b4fe52 Author: Ben Greear Date: 2011-08-08 (Mon, 08 Aug 2011) Changed paths: M xorp/win32_pkg.bash Log Message: ----------- Update win32_pkg script to build as well. Add notes on Fedora cross-compile packages. Signed-off-by: Ben Greear Commit: 8e36e8b439d83f0e69d40ce9c285e85aecf76e29 https://github.com/greearb/xorp.ct/commit/8e36e8b439d83f0e69d40ce9c285e85aecf76e29 Author: Ben Greear Date: 2011-08-08 (Mon, 08 Aug 2011) Changed paths: M docs/man/xorpsh.1 M docs/man/xorpsh.sgml Log Message: ----------- xorpsh manpage typo fixes Patch contributed by Jose Manuel dos Santos Calhariz Signed-off-by: Ben Greear Compare: https://github.com/greearb/xorp.ct/compare/a003c53...8e36e8b From mass3mass at gmail.com Tue Aug 9 12:16:52 2011 From: mass3mass at gmail.com (MAS .) Date: Wed, 10 Aug 2011 00:46:52 +0530 Subject: [Xorp-hackers] XORP for Marvell Message-ID: Hi All, I am masters student. We have one router board designed in our lab which uses Marvell switch chip, it has ARM and it runs Linux.* Is it possible to use XORP on that board*? There will be issues regarding lower-level design. How does FEA talks to the Marvel? Is there any material of wiki help which elaborate it more? I dont have much idea about this that is it doable? what kind of efforts should I have to put into it to make it work? Please Help me !!! Thanks in advance ! - - cheers to open-source community !! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110810/cc36c3fc/attachment.html From noreply at github.com Thu Aug 11 01:05:28 2011 From: noreply at github.com (noreply at github.com) Date: Thu, 11 Aug 2011 01:05:28 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 2d659d: Fix un-initialized variable in win32 specific code... Message-ID: <20110811080528.A29E542447@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 2d659deb947bf0b5146b05068f2b897567d81a3a https://github.com/greearb/xorp.ct/commit/2d659deb947bf0b5146b05068f2b897567d81a3a Author: Ben Greear Date: 2011-08-11 (Thu, 11 Aug 2011) Changed paths: M xorp/fea/data_plane/fibconfig/fibconfig_entry_set_iphelper.cc M xorp/win32_pkg.bash Log Message: ----------- Fix un-initialized variable in win32 specific code. This could cause problems adding/updating routes. Reported by iqor.com. Signed-off-by: Ben Greear From greearb at candelatech.com Thu Aug 11 01:11:10 2011 From: greearb at candelatech.com (Ben Greear) Date: Thu, 11 Aug 2011 01:11:10 -0700 Subject: [Xorp-hackers] XORP for Marvell In-Reply-To: References: Message-ID: <4E438E9E.3060707@candelatech.com> On 08/09/2011 12:16 PM, MAS . wrote: > Hi All, > > I am masters student. We have one router board designed in our lab which uses Marvell switch chip, it has ARM and it runs Linux.*Is it possible to use XORP on > that board*? There will be issues regarding lower-level design. How does FEA talks to the Marvel? Is there any material of wiki help which elaborate it more? If it runs linux, then it should run xorp OK. How does linux show the switch ports? 'ifconfig -a' would help for starters. > > I dont have much idea about this that is it doable? what kind of efforts should I have to put into it to make it work? Well, what are you actually trying to do? Thanks, Ben > > Please Help me !!! > > Thanks in advance ! > > > - - > cheers to open-source community !! > > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- Ben Greear Candela Technologies Inc http://www.candelatech.com From noreply at github.com Thu Aug 11 22:44:51 2011 From: noreply at github.com (noreply at github.com) Date: Thu, 11 Aug 2011 22:44:51 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 2b78e5: fea: Make io_ip_sockets non-blocking by default. Message-ID: <20110812054451.58C9D426B2@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 2b78e5c551e4926ec765f09b71d610274fa54468 https://github.com/greearb/xorp.ct/commit/2b78e5c551e4926ec765f09b71d610274fa54468 Author: Ben Greear Date: 2011-08-11 (Thu, 11 Aug 2011) Changed paths: M xorp/fea/data_plane/io/io_ip_socket.cc Log Message: ----------- fea: Make io_ip_sockets non-blocking by default. This *might* fix a hang reported on Windows. I can't think of a good reason for any of these sockets to be blocking anyway.... Signed-off-by: Ben Greear Commit: 1925203b788b6b244cb6dca822c44d046550984e https://github.com/greearb/xorp.ct/commit/1925203b788b6b244cb6dca822c44d046550984e Author: Ben Greear Date: 2011-08-11 (Thu, 11 Aug 2011) Changed paths: M xorp/fea/io_ip_manager.cc Log Message: ----------- fea: Add logging for register/unregister protocol handlers. Might help debug issues seen on Windows. Signed-off-by: Ben Greear Compare: https://github.com/greearb/xorp.ct/compare/2d659de...1925203 From noreply at github.com Thu Aug 11 23:37:14 2011 From: noreply at github.com (noreply at github.com) Date: Thu, 11 Aug 2011 23:37:14 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 42f7e5: Make package script smarter. Message-ID: <20110812063714.2BA0F42491@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 42f7e53d9cf92b88e994be35427a86b2ce65644f https://github.com/greearb/xorp.ct/commit/42f7e53d9cf92b88e994be35427a86b2ce65644f Author: Ben Greear Date: 2011-08-11 (Thu, 11 Aug 2011) Changed paths: M xorp/lf_pkg.bash Log Message: ----------- Make package script smarter. Signed-off-by: Ben Greear From jose.spam at netvisao.pt Mon Aug 15 05:39:35 2011 From: jose.spam at netvisao.pt (Jose Manuel dos Santos Calhariz) Date: Mon, 15 Aug 2011 13:39:35 +0100 Subject: [Xorp-hackers] xorp 1.8.3 compiled for Debian stable, not official packages Message-ID: <20110815123935.GA13032@calhariz.com> I have been working to prepare a new Debian package for xorp v1.8.3. While the work is not yet finished, I put online packages of xorp for Debian 6.0 (squeeze). This packages are not Debian official, so any bug please report to me, not to Debian. I don't have many means for testing them so report of success are important. http://blog.calhariz.com/post/2011/08/04/Preview-of-xorp-v1.8.3-in-Debian I don't mind if the packages copied to http://sourceforge.net/projects/xorp for easier download. My two goals for xorp in Debian are: - Finished the package so it can be accepted in unstable. - Find what is needed so xorp 1.8.3 is officially backported to stable. I can't give any estimate when this will done. I need to create private packages of xorp 1.8.3 for Debian 6.0, for use in my University. I will announce new versions of them in my blog and twitter account until they are officially accepted in Debian. http://blog.calhariz.com http://www.twitter.com/calhariz Jose Calhariz -- -- V?rus Politicamente Correto: Nunca se mostra como um v?rus. Prefere se denominar como micro-organismo eletr?nico. From naik.srinu at gmail.com Sun Aug 21 22:11:09 2011 From: naik.srinu at gmail.com (Srinivas Naik) Date: Mon, 22 Aug 2011 10:41:09 +0530 Subject: [Xorp-hackers] configuring Hold-time for PIM Message-ID: Hi, How can I set the Hold-time for PIM-SM. Is there any terminal command to configure? Please throw some light on it. Thanks in advance Naik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110822/06a93542/attachment.html From noreply at github.com Thu Aug 25 15:29:44 2011 From: noreply at github.com (noreply at github.com) Date: Thu, 25 Aug 2011 15:29:44 -0700 Subject: [Xorp-hackers] [greearb/xorp.ct] 63ea53: xrl: Add some debugging for stcp logic. Message-ID: <20110825222944.19FD74264E@smtp1.rs.github.com> Branch: refs/heads/master Home: https://github.com/greearb/xorp.ct Commit: 63ea53a70893a43988462d8418e846734616a171 https://github.com/greearb/xorp.ct/commit/63ea53a70893a43988462d8418e846734616a171 Author: root Date: 2011-08-25 (Thu, 25 Aug 2011) Changed paths: M xorp/libxipc/xrl_pf_stcp.cc M xorp/libxipc/xrl_pf_stcp.hh M xorp/libxorp/asyncio.cc M xorp/libxorp/asyncio.hh M xorp/libxorp/buffered_asyncio.cc M xorp/libxorp/buffered_asyncio.hh M xorp/libxorp/task.hh Log Message: ----------- xrl: Add some debugging for stcp logic. User sees this on windows...need to know more to fix it: ERROR ..\lib\xorp\sbin\xorp_fea.exe:512 XRL libxipc/xrl_pf_stcp.cc:799 die ] XrlPFSTCPSender died: Keepalive timeout^ Commit: 292c6491c8f0bf107ce2aee7e4fa24f0be4cc036 https://github.com/greearb/xorp.ct/commit/292c6491c8f0bf107ce2aee7e4fa24f0be4cc036 Author: Ben Greear Date: 2011-08-25 (Thu, 25 Aug 2011) Changed paths: M xorp/libxipc/xrl_pf.cc M xorp/libxipc/xrl_pf.hh M xorp/libxipc/xrl_pf_factory.cc M xorp/libxipc/xrl_pf_factory.hh M xorp/libxipc/xrl_pf_stcp.cc M xorp/libxipc/xrl_pf_stcp.hh M xorp/libxipc/xrl_pf_unix.cc M xorp/libxipc/xrl_pf_unix.hh M xorp/libxipc/xrl_router.cc Log Message: ----------- xrl: Allow meaningful name to identify xrl senders. Should help with debugging. Compare: https://github.com/greearb/xorp.ct/compare/42f7e53...292c649 From dan at midokura.com Fri Aug 26 15:54:24 2011 From: dan at midokura.com (Dan Mihai Dumitriu) Date: Sat, 27 Aug 2011 07:54:24 +0900 Subject: [Xorp-hackers] Thrift RPC support Message-ID: Hi all, A couple of years ago some work was started to lay the groundwork for supporting Thrift as the RPC mechanism. I was just wondering what the status of that is. It seems kind of dead from the mailing list. (http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2009-November/002242.html) Cheers, Dan From greearb at candelatech.com Fri Aug 26 20:58:02 2011 From: greearb at candelatech.com (Ben Greear) Date: Fri, 26 Aug 2011 20:58:02 -0700 Subject: [Xorp-hackers] Thrift RPC support In-Reply-To: References: Message-ID: <4E586B4A.8090902@candelatech.com> On 08/26/2011 03:54 PM, Dan Mihai Dumitriu wrote: > Hi all, > > A couple of years ago some work was started to lay the groundwork for > supporting Thrift as the RPC mechanism. I was just wondering what the > status of that is. It seems kind of dead from the mailing list. > (http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2009-November/002242.html) I don't think anyone is working on it, and unless someone can explain why it would be better than what we have now, I'm not overly excited about accepting patches that add dependencies on external frameworks. Do you have some project in mind that would benefit from using Thrift? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From dan at midokura.com Sun Aug 28 18:16:49 2011 From: dan at midokura.com (Dan Mihai Dumitriu) Date: Mon, 29 Aug 2011 10:16:49 +0900 Subject: [Xorp-hackers] Thrift RPC support In-Reply-To: <4E586B4A.8090902@candelatech.com> References: <4E586B4A.8090902@candelatech.com> Message-ID: Hi Ben, Thanks for the quick reply. I was just curious. I don't necessarily think that Thrift is better than what is there now. However, I want to write an interface to the RIB in Java, so the cross language issue came up. Do you have any suggestion, other than building it from scratch? :) Cheers, Dan On Sat, Aug 27, 2011 at 12:58 PM, Ben Greear wrote: > On 08/26/2011 03:54 PM, Dan Mihai Dumitriu wrote: >> >> Hi all, >> >> A couple of years ago some work was started to lay the groundwork for >> supporting Thrift as the RPC mechanism. ?I was just wondering what the >> status of that is. ?It seems kind of dead from the mailing list. >> >> (http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2009-November/002242.html) > > I don't think anyone is working on it, and unless someone can explain why > it would be better than what we have now, I'm not overly excited about > accepting patches that add dependencies on external frameworks. > > Do you have some project in mind that would benefit from using Thrift? > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc ?http://www.candelatech.com > From greearb at candelatech.com Mon Aug 29 00:57:58 2011 From: greearb at candelatech.com (Ben Greear) Date: Mon, 29 Aug 2011 00:57:58 -0700 Subject: [Xorp-hackers] Thrift RPC support In-Reply-To: References: <4E586B4A.8090902@candelatech.com> Message-ID: <4E5B4686.9030608@candelatech.com> On 08/28/2011 06:16 PM, Dan Mihai Dumitriu wrote: > Hi Ben, > > Thanks for the quick reply. I was just curious. > > I don't necessarily think that Thrift is better than what is there > now. However, I want to write an interface to the RIB in Java, so the > cross language issue came up. Do you have any suggestion, other than > building it from scratch? :) Seems like we could make the code that generates the c++ code from templates generate java classes as well. And would have to re-implement the xrl core logic in java. That probably wouldn't be too difficult, but I don't have time or interest to do it myself. I'd be happy to consider patches if someone else wants to work on it, however... Or, depending on your needs, you might be able to hard-code some java-xrl stuff without using template-generated java code, or even have the java code call c++ programs that do the messaging. Thanks, Ben > > Cheers, > Dan > > > On Sat, Aug 27, 2011 at 12:58 PM, Ben Greear wrote: >> On 08/26/2011 03:54 PM, Dan Mihai Dumitriu wrote: >>> >>> Hi all, >>> >>> A couple of years ago some work was started to lay the groundwork for >>> supporting Thrift as the RPC mechanism. I was just wondering what the >>> status of that is. It seems kind of dead from the mailing list. >>> >>> (http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2009-November/002242.html) >> >> I don't think anyone is working on it, and unless someone can explain why >> it would be better than what we have now, I'm not overly excited about >> accepting patches that add dependencies on external frameworks. >> >> Do you have some project in mind that would benefit from using Thrift? >> >> Thanks, >> Ben >> >> -- >> Ben Greear >> Candela Technologies Inc http://www.candelatech.com >> -- Ben Greear Candela Technologies Inc http://www.candelatech.com From dan at midokura.com Mon Aug 29 15:15:19 2011 From: dan at midokura.com (Dan Mihai Dumitriu) Date: Tue, 30 Aug 2011 07:15:19 +0900 Subject: [Xorp-hackers] Thrift RPC support In-Reply-To: <4E5B4686.9030608@candelatech.com> References: <4E586B4A.8090902@candelatech.com> <4E5B4686.9030608@candelatech.com> Message-ID: That is pretty much what I was thinking. We may implement the xrl in Java for this project, and if so we'll send patches. Cheers, Dan On Aug 29, 2011 4:58 PM, "Ben Greear" wrote: > On 08/28/2011 06:16 PM, Dan Mihai Dumitriu wrote: >> Hi Ben, >> >> Thanks for the quick reply. I was just curious. >> >> I don't necessarily think that Thrift is better than what is there >> now. However, I want to write an interface to the RIB in Java, so the >> cross language issue came up. Do you have any suggestion, other than >> building it from scratch? :) > > Seems like we could make the code that generates the c++ code from templates > generate java classes as well. And would have to re-implement the xrl core > logic in java. > > That probably wouldn't be too difficult, but I don't have time or interest to > do it myself. I'd be happy to consider patches if someone else wants to work > on it, however... > > Or, depending on your needs, you might be able to hard-code some java-xrl stuff without > using template-generated java code, or even have the java code call c++ programs > that do the messaging. > > Thanks, > Ben > >> >> Cheers, >> Dan >> >> >> On Sat, Aug 27, 2011 at 12:58 PM, Ben Greear wrote: >>> On 08/26/2011 03:54 PM, Dan Mihai Dumitriu wrote: >>>> >>>> Hi all, >>>> >>>> A couple of years ago some work was started to lay the groundwork for >>>> supporting Thrift as the RPC mechanism. I was just wondering what the >>>> status of that is. It seems kind of dead from the mailing list. >>>> >>>> ( http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2009-November/002242.html ) >>> >>> I don't think anyone is working on it, and unless someone can explain why >>> it would be better than what we have now, I'm not overly excited about >>> accepting patches that add dependencies on external frameworks. >>> >>> Do you have some project in mind that would benefit from using Thrift? >>> >>> Thanks, >>> Ben >>> >>> -- >>> Ben Greear >>> Candela Technologies Inc http://www.candelatech.com >>> > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20110830/3f5aa4e6/attachment.html From ss at comp.lancs.ac.uk Tue Aug 30 07:58:43 2011 From: ss at comp.lancs.ac.uk (Steven Simpson) Date: Tue, 30 Aug 2011 15:58:43 +0100 Subject: [Xorp-hackers] Floating-point types in IPC Message-ID: <4E5CFAA3.6000603@comp.lancs.ac.uk> Hi Ben, all, It's been pointed out to me that there are no floating-point types supported by XrlAtom, and we might need them in the ECODE project. Has there been any plan for adding them? How far did it get? What stopped it? I've gone through the motions of adding an fp64 type, conforming to IEEE754 binary64, so it should be able to transmit NaN and signed zero/infinity. It maps to an alias fp64_t, which is either double or long double. The implementation uses only C99 functions, so that should avoid introducing new dependencies. I've introduced which chooses the fp64_t alias, and which provides C functions for converting between fp64_t and uint_fast64_t. They should not need to be accessed directly by user code, as xrl_atom.hh handles it. The algorithm has been tested in isolation, but I haven't made a start yet on an integrated test - I guess something in libxipc/tests would be appropriate. From what I recall, enable_tests=True is required for programs in there. Let me know if that sounds up to scratch, and I'll send you the patch when I have the tests in place. Cheers, Steven From greearb at candelatech.com Tue Aug 30 08:37:08 2011 From: greearb at candelatech.com (Ben Greear) Date: Tue, 30 Aug 2011 08:37:08 -0700 Subject: [Xorp-hackers] Floating-point types in IPC In-Reply-To: <4E5CFAA3.6000603@comp.lancs.ac.uk> References: <4E5CFAA3.6000603@comp.lancs.ac.uk> Message-ID: <4E5D03A4.9060909@candelatech.com> On 08/30/2011 07:58 AM, Steven Simpson wrote: > Hi Ben, all, > > It's been pointed out to me that there are no floating-point types > supported by XrlAtom, and we might need them in the ECODE project. Has > there been any plan for adding them? How far did it get? What stopped it? > > I've gone through the motions of adding an fp64 type, conforming to > IEEE754 binary64, so it should be able to transmit NaN and signed > zero/infinity. It maps to an alias fp64_t, which is either double or > long double. The implementation uses only C99 functions, so that should > avoid introducing new dependencies. > > I've introduced which chooses the fp64_t alias, and > which provides C functions for converting between > fp64_t and uint_fast64_t. They should not need to be accessed directly > by user code, as xrl_atom.hh handles it. > > The algorithm has been tested in isolation, but I haven't made a start > yet on an integrated test - I guess something in libxipc/tests would be > appropriate. From what I recall, enable_tests=True is required for > programs in there. > > Let me know if that sounds up to scratch, and I'll send you the patch > when I have the tests in place. Sounds good to me. Thanks, Ben > > Cheers, > > Steven > > _______________________________________________ > Xorp-hackers mailing list > Xorp-hackers at icir.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers -- Ben Greear Candela Technologies Inc http://www.candelatech.com From ss at comp.lancs.ac.uk Wed Aug 31 04:55:03 2011 From: ss at comp.lancs.ac.uk (ss at comp.lancs.ac.uk) Date: Wed, 31 Aug 2011 12:55:03 +0100 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs In-Reply-To: <4E5CFAA3.6000603@comp.lancs.ac.uk> References: <4E5CFAA3.6000603@comp.lancs.ac.uk> Message-ID: <1314791703-23416-1-git-send-email-ss@comp.lancs.ac.uk> From: Steven Simpson * New atom type fp64 * selects alias fp64_t for most compatible native C type. Native type's characteristics are echoed with corresponding macros (analogous to DBL_MIN, etc). * (de)serializes fp64_t into uint_fast64_t. * New methods for fp64_t added on XrlAtom and XrlArgs. * Added fp64 to xif types, mapping to fp64_t in C++ and double for Thrift. * Extended atom and args tests to include fp64_t. * Added fp64_t serialization test. (It always succeeds for now, but might be useful for diagnostics.) * Added method to test XIF to demonstrate fp64 type. Signed-off-by: Steven Simpson --- xorp/libxipc/SConscript | 1 + xorp/libxipc/fp64.h | 198 ++++++++++++++++++++++++++++++ xorp/libxipc/fp64serial.c | 184 ++++++++++++++++++++++++++++ xorp/libxipc/fp64serial.h | 40 ++++++ xorp/libxipc/tests/SConscript | 1 + xorp/libxipc/tests/test_fp64.cc | 226 +++++++++++++++++++++++++++++++++++ xorp/libxipc/tests/test_xrl_args.cc | 5 +- xorp/libxipc/tests/test_xrl_atom.cc | 4 + xorp/libxipc/xrl_args.cc | 28 +++++ xorp/libxipc/xrl_args.hh | 24 ++++ xorp/libxipc/xrl_atom.cc | 55 +++++++++- xorp/libxipc/xrl_atom.hh | 19 +++- xorp/rtrmgr/xorp_client.cc | 1 + xorp/xrl/interfaces/test.xif | 5 + xorp/xrl/scripts/Xif/xiftypes.py | 3 +- 15 files changed, 790 insertions(+), 4 deletions(-) create mode 100644 xorp/libxipc/fp64.h create mode 100644 xorp/libxipc/fp64serial.c create mode 100644 xorp/libxipc/fp64serial.h create mode 100644 xorp/libxipc/tests/test_fp64.cc diff --git a/xorp/libxipc/SConscript b/xorp/libxipc/SConscript index 104bc8e..e7cf973 100644 --- a/xorp/libxipc/SConscript +++ b/xorp/libxipc/SConscript @@ -87,6 +87,7 @@ libxipc_sources = [ 'xrl_std_router.cc', 'xrl_tokens.cc', 'xuid.cc', # only for udp (and fea tcpudp mgr) + 'fp64serial.c', ] # deal with shared objects diff --git a/xorp/libxipc/fp64.h b/xorp/libxipc/fp64.h new file mode 100644 index 0000000..8e49a19 --- /dev/null +++ b/xorp/libxipc/fp64.h @@ -0,0 +1,198 @@ +// -*- c-basic-offset: 4; tab-width: 8; indent-tabs-mode: t -*- +// vim:set sts=4 ts=8: + +// Copyright (c) 2001-2011 XORP, Inc and Others +// +// This program is free software; you can redistribute it and/or modify +// it under the terms of the GNU Lesser General Public License, Version +// 2.1, June 1999 as published by the Free Software Foundation. +// Redistribution and/or modification of this program under the terms of +// any other version of the GNU Lesser General Public License is not +// permitted. +// +// This program is distributed in the hope that it will be useful, but +// WITHOUT ANY WARRANTY; without even the implied warranty of +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For more details, +// see the GNU Lesser General Public License, Version 2.1, a copy of +// which can be found in the XORP LICENSE.lgpl file. +// +// XORP, Inc, 2953 Bunker Hill Lane, Suite 204, Santa Clara, CA 95054, USA; +// http://xorp.net + +// $XORP: xorp/libxipc/xrl_atom.hh,v 1.23 2008/10/30 20:49:07 pavlin Exp $ + +#ifndef __LIBXIPC_FP64_H__ +#define __LIBXIPC_FP64_H__ + +#include +#include + +/* This header chooses a native real type (float, double, long double) + which best matches the IEEE754 binary64 capabilities. */ + + + +/* These are the target characteristics of various IEEE754 types, + expressed in terms that make them comparable to the native real + types. */ + +/* TODO: We only need the 64-bit details; the others could be in their + own header. */ + +#define XORP_IEEE754_BIN16_MANT_DIG 11 +#define XORP_IEEE754_BIN16_MAX_EXP 16 +#define XORP_IEEE754_BIN16_MIN_EXP -13 + +#define XORP_IEEE754_BIN32_MANT_DIG 24 +#define XORP_IEEE754_BIN32_MAX_EXP 128 +#define XORP_IEEE754_BIN32_MIN_EXP -125 + +#define XORP_IEEE754_BIN64_MANT_DIG 53 +#define XORP_IEEE754_BIN64_MAX_EXP 1024 +#define XORP_IEEE754_BIN64_MIN_EXP -1021 + +#define XORP_IEEE754_BIN128_MANT_DIG 113 +#define XORP_IEEE754_BIN128_MAX_EXP 16384 +#define XORP_IEEE754_BIN128_MIN_EXP -16381 + + +/* TODO: These ratios and test macros are not binary64-specific. If + other types were to be supported, these macros should be factored + out. */ + +/* These are 100000*log2(FLT_RADIX) for various possible FLT_RADIX + values. In comparing the capabilities of float, double and long + double with binary64, we need to account for the slim possibility + that our native base is not 2, while binary64's base is 2. */ + +#define XORP_IEEE754_RADIX_RATIO_2 1000000 +#define XORP_IEEE754_RADIX_RATIO_3 1584963 +#define XORP_IEEE754_RADIX_RATIO_4 2000000 +#define XORP_IEEE754_RADIX_RATIO_5 2321928 +#define XORP_IEEE754_RADIX_RATIO_6 2584963 +#define XORP_IEEE754_RADIX_RATIO_7 2807354 +#define XORP_IEEE754_RADIX_RATIO_8 3000000 +#define XORP_IEEE754_RADIX_RATIO_9 3169925 +#define XORP_IEEE754_RADIX_RATIO_10 3321928 + +#define XORP_IEEE754_RADIX_RATIO_N(B) (XORP_IEEE754_RADIX_RATIO_ ## B) +#define XORP_IEEE754_RADIX_RATIO(B) (XORP_IEEE754_RADIX_RATIO_N(B)) + + +/* These preprocessor-safe macros test various native types' + characteristics against IEEE754 types'. */ + +#define XORP_IEEE754_TEST_MANT_DIG(T,W) \ + ( T ## _MANT_DIG * XORP_IEEE754_RADIX_RATIO(FLT_RADIX) >= \ + XORP_IEEE754_BIN ## W ## _MANT_DIG * XORP_IEEE754_RADIX_RATIO_2 ) + +#define XORP_IEEE754_TEST_MAX_EXP(T,W) \ + ( T ## _MAX_EXP * XORP_IEEE754_RADIX_RATIO(FLT_RADIX) >= \ + XORP_IEEE754_BIN ## W ## _MAX_EXP * XORP_IEEE754_RADIX_RATIO_2 ) + +#define XORP_IEEE754_TEST_MIN_EXP(T,W) \ + ( T ## _MIN_EXP * XORP_IEEE754_RADIX_RATIO(FLT_RADIX) <= \ + XORP_IEEE754_BIN ## W ## _MIN_EXP * XORP_IEEE754_RADIX_RATIO_2) + +#define XORP_IEEE754_TEST(T,W) \ + ( XORP_IEEE754_TEST_MANT_DIG(T,W) && \ + XORP_IEEE754_TEST_MAX_EXP(T,W) && \ + XORP_IEEE754_TEST_MIN_EXP(T,W) ) + +/* Now we choose a native type to fulfil binary64. */ + +#if XORP_IEEE754_TEST(DBL,64) +/* double is sufficient, and is probably the optimal FP type used by + this system. */ +#define XORP_IEEE754_BIN64_DBL 1 +#else +/* We'll have to use long double, and hope that it is adequate. What + other choice do we have? */ +#define XORP_IEEE754_BIN64_LDBL 1 +#endif + + +/* Declare a type alias according to what we've chosen. Also define + some macros (like those in ) to print and scan the + type. */ + +#if XORP_IEEE754_BIN64_FLT +typedef float fp64_t; +#define XORP_PRIaFP64 "a" +#define XORP_PRIeFP64 "e" +#define XORP_PRIfFP64 "f" +#define XORP_PRIgFP64 "g" +#define XORP_PRIAFP64 "A" +#define XORP_PRIEFP64 "E" +#define XORP_PRIFFP64 "F" +#define XORP_PRIGFP64 "G" +#define XORP_SCNaFP64 "a" +#define XORP_SCNeFP64 "e" +#define XORP_SCNfFP64 "f" +#define XORP_SCNgFP64 "g" +#define XORP_FP64(F) F ## f +#define XORP_FP64_DIG FLT_FP64_DIG +#define XORP_FP64_EPSILON FLT_FP64_EPSILON +#define XORP_FP64_MANT_DIG FLT_FP64_MANT_DIG +#define XORP_FP64_MAX FLT_FP64_MAX +#define XORP_FP64_MAX_10_EXP FLT_FP64_MAX_10_EXP +#define XORP_FP64_MAX_EXP FLT_FP64_MAX_EXP +#define XORP_FP64_MIN FLT_FP64_MIN +#define XORP_FP64_MIN_10_EXP FLT_FP64_MIN_10_EXP +#define XORP_FP64_MIN_EXP FLT_FP64_MIN_EXP +#endif + +#if XORP_IEEE754_BIN64_DBL +typedef double fp64_t; +#define XORP_PRIaFP64 "a" +#define XORP_PRIeFP64 "e" +#define XORP_PRIfFP64 "f" +#define XORP_PRIgFP64 "g" +#define XORP_PRIAFP64 "A" +#define XORP_PRIEFP64 "E" +#define XORP_PRIFFP64 "F" +#define XORP_PRIGFP64 "G" +#define XORP_SCNaFP64 "la" +#define XORP_SCNeFP64 "le" +#define XORP_SCNfFP64 "lf" +#define XORP_SCNgFP64 "lg" +#define XORP_FP64(F) F +#define XORP_FP64_DIG DBL_FP64_DIG +#define XORP_FP64_EPSILON DBL_FP64_EPSILON +#define XORP_FP64_MANT_DIG DBL_FP64_MANT_DIG +#define XORP_FP64_MAX DBL_FP64_MAX +#define XORP_FP64_MAX_10_EXP DBL_FP64_MAX_10_EXP +#define XORP_FP64_MAX_EXP DBL_FP64_MAX_EXP +#define XORP_FP64_MIN DBL_FP64_MIN +#define XORP_FP64_MIN_10_EXP DBL_FP64_MIN_10_EXP +#define XORP_FP64_MIN_EXP DBL_FP64_MIN_EXP +#endif + +#if XORP_IEEE754_BIN64_LDBL +typedef long double fp64_t; +#define XORP_PRIaFP64 "La" +#define XORP_PRIeFP64 "Le" +#define XORP_PRIfFP64 "Lf" +#define XORP_PRIgFP64 "Lg" +#define XORP_PRIAFP64 "LA" +#define XORP_PRIEFP64 "LE" +#define XORP_PRIFFP64 "LF" +#define XORP_PRIGFP64 "LG" +#define XORP_SCNaFP64 "La" +#define XORP_SCNeFP64 "Le" +#define XORP_SCNfFP64 "Lf" +#define XORP_SCNgFP64 "Lg" +#define XORP_FP64(F) F ## l +#define XORP_FP64_DIG LDBL_FP64_DIG +#define XORP_FP64_EPSILON LDBL_FP64_EPSILON +#define XORP_FP64_MANT_DIG LDBL_FP64_MANT_DIG +#define XORP_FP64_MAX LDBL_FP64_MAX +#define XORP_FP64_MAX_10_EXP LDBL_FP64_MAX_10_EXP +#define XORP_FP64_MAX_EXP LDBL_FP64_MAX_EXP +#define XORP_FP64_MIN LDBL_FP64_MIN +#define XORP_FP64_MIN_10_EXP LDBL_FP64_MIN_10_EXP +#define XORP_FP64_MIN_EXP LDBL_FP64_MIN_EXP +#endif + + +#endif diff --git a/xorp/libxipc/fp64serial.c b/xorp/libxipc/fp64serial.c new file mode 100644 index 0000000..e61329f --- /dev/null +++ b/xorp/libxipc/fp64serial.c @@ -0,0 +1,184 @@ +// -*- c-basic-offset: 4; tab-width: 8; indent-tabs-mode: t -*- +// vim:set sts=4 ts=8: + +// Copyright (c) 2001-2011 XORP, Inc and Others +// +// This program is free software; you can redistribute it and/or modify +// it under the terms of the GNU Lesser General Public License, Version +// 2.1, June 1999 as published by the Free Software Foundation. +// Redistribution and/or modification of this program under the terms of +// any other version of the GNU Lesser General Public License is not +// permitted. +// +// This program is distributed in the hope that it will be useful, but +// WITHOUT ANY WARRANTY; without even the implied warranty of +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For more details, +// see the GNU Lesser General Public License, Version 2.1, a copy of +// which can be found in the XORP LICENSE.lgpl file. +// +// XORP, Inc, 2953 Bunker Hill Lane, Suite 204, Santa Clara, CA 95054, USA; +// http://xorp.net + +#include +#include +#include +#include + +#include "fp64serial.h" + +/* How big are the fields of IEEE754 binary64? */ +#define MANTISSA_BIT 52 +#define EXPONENT_BIT 11 +#define SIGN_BIT 1 + +/* What's the offset for each field? */ +#define MANTISSA_SHIFT 0 +#define EXPONENT_SHIFT (MANTISSA_SHIFT + MANTISSA_BIT) +#define SIGN_SHIFT (EXPONENT_SHIFT + EXPONENT_BIT) + +/* Compute masks for each field. */ +#define MANTISSA_MASK ((UINTMAX_C(1) << MANTISSA_BIT) - 1u) +#define EXPONENT_MASK ((UINTMAX_C(1) << EXPONENT_BIT) - 1u) +#define SIGN_MASK ((UINTMAX_C(1) << SIGN_BIT) - 1u) + +/* How much is the exponent biased? */ +#define EXPONENT_BIAS ((EXPONENT_MASK >> 1u) - 1u) + + +uint_fast64_t fp64enc(fp64_t input) +{ + fp64_t d_mant; + unsigned int u_exp; + uint_fast64_t u_mant; + bool neg; + int s_exp; + uint_fast64_t bytes; + + switch (fpclassify(input)) { + default: + abort(); + break; + + case FP_ZERO: + neg = signbit(input); + u_mant = 0; + u_exp = 0; + break; + + case FP_INFINITE: + neg = signbit(input); + u_mant = 0; + u_exp = EXPONENT_MASK; + break; + + case FP_NAN: + neg = false; + u_mant = 1; + u_exp = EXPONENT_MASK; + break; + + case FP_SUBNORMAL: + case FP_NORMAL: + /* Handle normal and subnormal together. The number might be + one class for double, but another for binary64. */ + + /* Decompose the input into a significand (mantissa + 1) and + an exponent. */ + d_mant = XORP_FP64(frexp)(input, &s_exp); + + /* Extract the sign bit from the mantissa. */ + neg = signbit(input); + d_mant = XORP_FP64(fabs)(d_mant); + + /* Offset the exponent so it can be represented as an unsigned + value. */ + s_exp += EXPONENT_BIAS; + + /* Now we find out whether the number we represent is normal, + subnormal, or overflows binary64. */ + if (s_exp >= (long) EXPONENT_MASK) { + /* The number is too big for binary64, so use the maximum + value. */ + u_mant = MANTISSA_MASK; + u_exp = EXPONENT_MASK - 1u; + } else if (s_exp <= 0) { + /* The number is subnormal in binary64. */ + + /* Shift the mantissa so that it's exponent would be 0. */ + u_mant = XORP_FP64(ldexp)(d_mant, MANTISSA_BIT); + + u_mant >>= -s_exp; + u_exp = 0; + } else { + /* The number is normal in binary64. */ + + /* Use the suggested exponent. */ + u_exp = s_exp; + + /* Make the mantissa value into a positive integer. */ + u_mant = XORP_FP64(ldexp)(d_mant, MANTISSA_BIT + 1); + } + + break; + } + + /* Transmit the bottom MANTISSA_BITs of u_mant. The extra top bit + will always be one when normalized. */ + + bytes = ((uint_fast64_t) u_mant & MANTISSA_MASK) << MANTISSA_SHIFT; + bytes |= ((uint_fast64_t) u_exp & EXPONENT_MASK) << EXPONENT_SHIFT; + bytes |= ((uint_fast64_t) neg & SIGN_MASK) << SIGN_SHIFT; + + return bytes; +} + +fp64_t fp64dec(uint_fast64_t bytes) +{ + int s_exp; + unsigned int u_exp; + uint_fast64_t u_mant; + bool neg; + fp64_t output; + + /* Extract the bit fields. */ + u_exp = (bytes >> EXPONENT_SHIFT) & EXPONENT_MASK; + u_mant = (bytes >> MANTISSA_SHIFT) & MANTISSA_MASK; + neg = (bytes >> SIGN_SHIFT) & SIGN_MASK; + + if (u_exp == EXPONENT_MASK) { + if (u_mant == 0) + return neg ? -INFINITY : +INFINITY; + return NAN; + } + + + do { + if (u_exp == 0) { + /* Positive or negative zero */ + if (u_mant == 0) + return XORP_FP64(copysign)(0.0, neg ? -1.0 : +1.0); + + /* Subnormal value */ + + /* Multiply the mantissa by a power of two. */ + output = XORP_FP64(ldexp) + (u_mant, -(MANTISSA_BIT + (int) EXPONENT_BIAS)); + break; + } + + /* Recover the top bit of the mantissa. */ + u_mant |= MANTISSA_MASK + 1; + + /* Convert offset exponent back into a native signed value. */ + s_exp = (int) u_exp - EXPONENT_BIAS; + + /* Multiply the mantissa by a power of two. */ + output = XORP_FP64(ldexp) + (u_mant, s_exp - (MANTISSA_BIT + 1)); + } while (false); + + if (neg) + output = -output; + + return output; +} diff --git a/xorp/libxipc/fp64serial.h b/xorp/libxipc/fp64serial.h new file mode 100644 index 0000000..e07ae73 --- /dev/null +++ b/xorp/libxipc/fp64serial.h @@ -0,0 +1,40 @@ +// -*- c-basic-offset: 4; tab-width: 8; indent-tabs-mode: t -*- +// vim:set sts=4 ts=8: + +// Copyright (c) 2001-2011 XORP, Inc and Others +// +// This program is free software; you can redistribute it and/or modify +// it under the terms of the GNU Lesser General Public License, Version +// 2.1, June 1999 as published by the Free Software Foundation. +// Redistribution and/or modification of this program under the terms of +// any other version of the GNU Lesser General Public License is not +// permitted. +// +// This program is distributed in the hope that it will be useful, but +// WITHOUT ANY WARRANTY; without even the implied warranty of +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For more details, +// see the GNU Lesser General Public License, Version 2.1, a copy of +// which can be found in the XORP LICENSE.lgpl file. +// +// XORP, Inc, 2953 Bunker Hill Lane, Suite 204, Santa Clara, CA 95054, USA; +// http://xorp.net + +// $XORP: xorp/libxipc/xrl_atom.hh,v 1.23 2008/10/30 20:49:07 pavlin Exp $ + +#ifndef __LIBXIPC_FP64SERIAL_H__ +#define __LIBXIPC_FP64SERIAL_H__ + +#include "fp64.h" + +#ifdef __cplusplus +extern "C" { +#endif + + extern uint_fast64_t fp64enc(fp64_t); + extern fp64_t fp64dec(uint_fast64_t); + +#ifdef __cplusplus +} +#endif + +#endif diff --git a/xorp/libxipc/tests/SConscript b/xorp/libxipc/tests/SConscript index d6d9b8b..4b1d611 100644 --- a/xorp/libxipc/tests/SConscript +++ b/xorp/libxipc/tests/SConscript @@ -70,6 +70,7 @@ simple_cpp_tests = [ 'xrl_error', 'xrl_parser', 'xrl_router', + 'fp64', ] xrlrcvr_sources = [ diff --git a/xorp/libxipc/tests/test_fp64.cc b/xorp/libxipc/tests/test_fp64.cc new file mode 100644 index 0000000..66417d7 --- /dev/null +++ b/xorp/libxipc/tests/test_fp64.cc @@ -0,0 +1,226 @@ +// -*- c-basic-offset: 4; tab-width: 8; indent-tabs-mode: t -*- +// vim:set sts=4 ts=8: + +// Copyright (c) 2001-2009 XORP, Inc. +// +// This program is free software; you can redistribute it and/or modify +// it under the terms of the GNU Lesser General Public License, Version +// 2.1, June 1999 as published by the Free Software Foundation. +// Redistribution and/or modification of this program under the terms of +// any other version of the GNU Lesser General Public License is not +// permitted. +// +// This program is distributed in the hope that it will be useful, but +// WITHOUT ANY WARRANTY; without even the implied warranty of +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For more details, +// see the GNU Lesser General Public License, Version 2.1, a copy of +// which can be found in the XORP LICENSE.lgpl file. +// +// XORP, Inc, 2953 Bunker Hill Lane, Suite 204, Santa Clara, CA 95054, USA; +// http://xorp.net + + + +// test_xrl_args: String Serialization Tests + +// Needed for PRIXFAST64 +#define __STDC_FORMAT_MACROS 1 + +#include +#include + +#include "xrl_module.h" + +#include "libxorp/xorp.h" +#include "libxorp/xlog.h" + +#ifdef HAVE_GETOPT_H +#include +#endif + +#include "xrl_args.hh" +#include "fp64serial.h" + + +/////////////////////////////////////////////////////////////////////////////// +// +// Constants +// + +static const char *program_name = "test_fp64"; +static const char *program_description = "Test IEEE754-fp64_t conversion"; +static const char *program_version_id = "0.1"; +static const char *program_date = "August, 2011"; +static const char *program_copyright = "See file LICENSE"; +static const char *program_return_value = "0 on success, 1 if test error, " + "2 if internal error"; + +/////////////////////////////////////////////////////////////////////////////// +// +// Verbosity level control +// + +static bool s_verbose = false; +bool verbose() { return s_verbose; } +void set_verbose(bool v) { s_verbose = v; } + +#define verbose_log(x...) _verbose_log(__FILE__,__LINE__, x) + +#define _verbose_log(file, line, x...) \ +do { \ + if (verbose()) { \ + printf("From %s:%d: ", file, line); \ + printf(x); \ + } \ +} while(0) + +/** + * Print program info to output stream. + * + * @param stream the output stream the print the program info to. + */ +static void +print_program_info(FILE *stream) +{ + fprintf(stream, "Name: %s\n", program_name); + fprintf(stream, "Description: %s\n", program_description); + fprintf(stream, "Version: %s\n", program_version_id); + fprintf(stream, "Date: %s\n", program_date); + fprintf(stream, "Copyright: %s\n", program_copyright); + fprintf(stream, "Return: %s\n", program_return_value); +} + +/** + * Print program usage information to the stderr. + * + * @param progname the name of the program. + */ +static void +usage(const char* progname) +{ + print_program_info(stderr); + fprintf(stderr, "usage: %s [-v] [-h]\n", progname); + fprintf(stderr, " -h : usage (this message)\n"); + fprintf(stderr, " -v : verbose output\n"); +} + +static double error_threshold; + +static int test_conversion(fp64_t input) +{ + uint_fast64_t encoded = fp64enc(input); + fp64_t output = fp64dec(encoded); + + fp64_t diff = output - input; + if (verbose()) + fprintf(stderr, "%15" XORP_PRIgFP64 " %016" PRIXFAST64 + " %15" XORP_PRIgFP64 " %15" XORP_PRIgFP64 "\n", + input, encoded, output, diff); + if (diff > error_threshold) { + verbose_log("THRESHOLD EXCEEDED\n"); + return 1; + } + return 0; +} + +static int +run_test() +{ + error_threshold = ldexp(1.0, 3 - DBL_MANT_DIG); + + + verbose_log("\n***** Expanding from DBL_MIN\n"); + for (double input = DBL_MIN; fpclassify(input) == FP_NORMAL; + input *= rand() * 50.0 / RAND_MAX) { + test_conversion(input); + } + + verbose_log("\n***** Expanding from -DBL_MIN\n"); + for (double input = -DBL_MIN; fpclassify(input) == FP_NORMAL; + input *= rand() * 50.0 / RAND_MAX) { + test_conversion(input); + } + + verbose_log("\n***** Reducinging from largest +ve subnormal\n"); + for (double input = nextafter(DBL_MIN, 0.0); fpclassify(input) != FP_ZERO; + input /= rand() * 50.0 / RAND_MAX) { + test_conversion(input); + } + + verbose_log("\n***** Reducinging from largest -ve subnormal\n"); + for (double input = -nextafter(DBL_MIN, 0.0); fpclassify(input) != FP_ZERO; + input /= rand() * 50.0 / RAND_MAX) { + test_conversion(input); + } + + + verbose_log("\n***** Infinities\n"); + test_conversion(+INFINITY); + test_conversion(-INFINITY); + + + verbose_log("\n***** Zeroes\n"); + test_conversion(+0.0); + test_conversion(-0.0); + +#ifdef NAN + verbose_log("\n***** NANs\n"); + test_conversion(NAN); +#endif + + return 0; +} + +int +main(int argc, char * const argv[]) +{ + srand(time(NULL)); + + int ret_value; + const char* const argv0 = argv[0]; + + int ch; + while ((ch = getopt(argc, argv, "hv")) != -1) { + switch (ch) { + case 'v': + set_verbose(true); + break; + case 'h': + case '?': + default: + usage(argv[0]); + if (ch == 'h') + return 0; + else + return 1; + } + } + argc -= optind; + argv += optind; + + // + // Initialize and start xlog + // + xlog_init(argv0, NULL); + xlog_set_verbose(XLOG_VERBOSE_LOW); // Least verbose messages + // XXX: verbosity of the error messages temporary increased + xlog_level_set_verbose(XLOG_LEVEL_ERROR, XLOG_VERBOSE_HIGH); + xlog_add_default_output(); + xlog_start(); + + XorpUnexpectedHandler x(xorp_unexpected_handler); + try { + ret_value = run_test(); + } + catch (...) { + xorp_catch_standard_exceptions(); + ret_value = 2; + } + // + // Gracefully stop and exit xlog + // + xlog_stop(); + xlog_exit(); + + return ret_value; +} diff --git a/xorp/libxipc/tests/test_xrl_args.cc b/xorp/libxipc/tests/test_xrl_args.cc index a4afcb4..f929957 100644 --- a/xorp/libxipc/tests/test_xrl_args.cc +++ b/xorp/libxipc/tests/test_xrl_args.cc @@ -168,7 +168,8 @@ run_serialization_test() XrlAtom("binary_data", test_binary), XrlAtom("a_list", test_list), XrlAtom("integer64", int64_t(-1234567890123456789LL)), - XrlAtom("uinteger64", uint64_t(0xabadc0ffee123456ULL)) + XrlAtom("uinteger64", uint64_t(0xabadc0ffee123456ULL)), + XrlAtom("fp64", fp64_t(0.087613017887164087613407)) }; uint32_t n_test_args = sizeof(test_args) / sizeof(test_args[0]); @@ -211,6 +212,7 @@ run_test() al.add_string("bad_karma", ""); al.add_int64("a_named_int64", int64_t(-98765432101234LL)); al.add_uint64("a_named_uint64", uint64_t(123456789012345ULL)); + al.add_fp64("a_named_fp64", fp64_t(0.087613017887164087613407)); XrlAtomList xal; xal.append(XrlAtom("first", string("fooo"))); @@ -260,6 +262,7 @@ run_test() al.get_string("bad_karma"); al.get_int64("a_named_int64"); al.get_uint64("a_named_uint64"); + al.get_fp64("a_named_fp64"); } catch (XrlArgs::BadArgs& e) { verbose_log("Error decoding the argument: %s\n", e.str().c_str()); return 1; diff --git a/xorp/libxipc/tests/test_xrl_atom.cc b/xorp/libxipc/tests/test_xrl_atom.cc index 280bc6b..dd3beed 100644 --- a/xorp/libxipc/tests/test_xrl_atom.cc +++ b/xorp/libxipc/tests/test_xrl_atom.cc @@ -242,6 +242,10 @@ test() test_atom(XrlAtom("test_uint64_value", uint64_t(0xabadc0ffee123456ULL))); break; + case xrlatom_fp64: + test_atom(XrlAtom("test_fp64_value", + fp64_t(0.087613017887164087613407))); + break; } } } diff --git a/xorp/libxipc/xrl_args.cc b/xorp/libxipc/xrl_args.cc index 5ca4a35..0297a49 100644 --- a/xorp/libxipc/xrl_args.cc +++ b/xorp/libxipc/xrl_args.cc @@ -536,6 +536,34 @@ XrlArgs::remove_uint64(const char* name) throw (XrlAtomNotFound) // ---------------------------------------------------------------------------- +// XrlArgs add/get/remove fp64 + +XrlArgs& +XrlArgs::add_fp64(const char* name, fp64_t val) throw (XrlAtomFound) +{ + return add(XrlAtom(name, val)); +} + +const fp64_t& +XrlArgs::get_fp64(const char* name) const throw (BadArgs) +{ + try { + return get(XrlAtom(name, xrlatom_fp64)).fp64(); + } catch (const XrlAtom::NoData& e) { + xorp_throw(BadArgs, e.why()); + } catch (const XrlAtom::WrongType& e) { + xorp_throw(BadArgs, e.why()); + } +} + +void +XrlArgs::remove_fp64(const char* name) throw (XrlAtomNotFound) +{ + remove(XrlAtom(name, xrlatom_fp64)); +} + + +// ---------------------------------------------------------------------------- // Append an existing XrlArgs XrlArgs& diff --git a/xorp/libxipc/xrl_args.hh b/xorp/libxipc/xrl_args.hh index e00338d..6c207aa 100644 --- a/xorp/libxipc/xrl_args.hh +++ b/xorp/libxipc/xrl_args.hh @@ -254,6 +254,18 @@ public: void get(const char* n, uint64_t& t) const throw (BadArgs); + /* --- fp64 accessors --- */ + + XrlArgs& add_fp64(const char* name, fp64_t v) throw (XrlAtomFound); + + const fp64_t& get_fp64(const char* name) const throw (BadArgs); + + void remove_fp64(const char* name) throw (XrlAtomNotFound); + + XrlArgs& add(const char* n, fp64_t v) throw (XrlAtomFound); + + void get(const char* n, fp64_t& t) const throw (BadArgs); + // ... Add your type's add, get, remove functions here ... @@ -518,6 +530,18 @@ XrlArgs::get(const char* n, uint64_t& t) const throw (BadArgs) t = get_uint64(n); } +inline XrlArgs& +XrlArgs::add(const char* n, fp64_t v) throw (XrlAtomFound) +{ + return add_fp64(n, v); +} + +inline void +XrlArgs::get(const char* n, fp64_t& t) const throw (BadArgs) +{ + t = get_fp64(n); +} + inline const XrlAtom& XrlArgs::item(uint32_t index) const { diff --git a/xorp/libxipc/xrl_atom.cc b/xorp/libxipc/xrl_atom.cc index 2cdc6e1..5106e4a 100644 --- a/xorp/libxipc/xrl_atom.cc +++ b/xorp/libxipc/xrl_atom.cc @@ -31,7 +31,7 @@ #include "libproto/packet.hh" - +#include "fp64serial.h" #ifdef HAVE_SYS_TYPES_H #include @@ -62,6 +62,7 @@ static const char* xrlatom_list_name = "list"; static const char* xrlatom_binary_name = "binary"; static const char* xrlatom_int64_name = "i64"; static const char* xrlatom_uint64_name = "u64"; +static const char* xrlatom_fp64_name = "fp64"; static inline void do_pack_uint32(const uint32_t u32val, uint8_t* buffer) @@ -97,6 +98,7 @@ xrlatom_type_name(const XrlAtomType& t) NAME_CASE(xrlatom_binary); NAME_CASE(xrlatom_int64); NAME_CASE(xrlatom_uint64); + NAME_CASE(xrlatom_fp64); // ... Your type here ... } return xrlatom_no_type_name; @@ -125,6 +127,7 @@ resolve_xrlatom_name(const char* name) CHECK_NAME(xrlatom_binary); /* FALLTHRU */ CHECK_NAME(xrlatom_int64); /* FALLTHRU */ CHECK_NAME(xrlatom_uint64); /* FALLTHRU */ + CHECK_NAME(xrlatom_fp64); /* FALLTHRU */ // ... Your type here ... case xrlatom_no_type: break; @@ -220,6 +223,9 @@ XrlAtom::data_from_c_str(const char* c_str) _u64val = (uint64_t)strtoull(c_str, (char**)NULL, 10); #endif break; + case xrlatom_fp64: + sscanf(c_str, "%" XORP_SCNgFP64, &_fp64val); + break; // ... Your types instantiator here ... } @@ -356,6 +362,13 @@ XrlAtom::uint64() const throw (NoData, WrongType) return _u64val; } +const fp64_t& +XrlAtom::fp64() const throw (NoData, WrongType) +{ + type_and_data_okay(xrlatom_fp64); + return _fp64val; +} + // ---------------------------------------------------------------------------- // XrlAtom dynamic data management functions @@ -415,6 +428,9 @@ XrlAtom::copy(const XrlAtom& xa) case xrlatom_uint64: _u64val = xa._u64val; break; + case xrlatom_fp64: + _fp64val = xa._fp64val; + break; // ... Your type's copy operation here ... case xrlatom_no_type: @@ -461,6 +477,7 @@ XrlAtom::discard_dynamic() break; case xrlatom_int64: case xrlatom_uint64: + case xrlatom_fp64: break; // ... Your type should free allocated memory here ... @@ -608,6 +625,10 @@ XrlAtom::value() const static_cast(_u64val)); #endif return xrlatom_encode_value(tmp, strlen(tmp)); + case xrlatom_fp64: + snprintf(tmp, sizeof(tmp) / sizeof(tmp[0]), + "%" XORP_PRIAFP64, _fp64val); + return xrlatom_encode_value(tmp, strlen(tmp)); // ... Your type's c_str equivalent here ... } @@ -682,6 +703,9 @@ XrlAtom::operator==(const XrlAtom& other) const case xrlatom_uint64: mv = (_u64val == other._u64val); break; + case xrlatom_fp64: + mv = (_fp64val == other._fp64val); + break; // ... Your type's equality test here ... } @@ -765,6 +789,7 @@ XrlAtom::packed_bytes() const break; case xrlatom_int64: case xrlatom_uint64: + case xrlatom_fp64: bytes += 8; break; @@ -790,6 +815,7 @@ XrlAtom::packed_bytes_fixed() const case xrlatom_boolean: case xrlatom_int64: case xrlatom_uint64: + case xrlatom_fp64: return true; case xrlatom_mac: case xrlatom_text: @@ -1169,6 +1195,27 @@ XrlAtom::unpack_uint64(const uint8_t* buf) } size_t +XrlAtom::pack_fp64(uint8_t* buffer) const +{ + uint_fast64_t bytes = fp64enc(_fp64val); + + do_pack_uint32(bytes >> 32, buffer); + do_pack_uint32(bytes & 0xFFFFFFFF, &buffer[4]); + return sizeof(_fp64val); +} + +size_t +XrlAtom::unpack_fp64(const uint8_t* buf) +{ + uint_fast64_t bytes; + bytes = uint_fast64_t(do_unpack_uint32(buf)) << 32; + bytes |= do_unpack_uint32(&buf[4]); + + _fp64val = fp64dec(bytes); + return sizeof(_fp64val); +} + +size_t XrlAtom::pack(uint8_t* buffer, size_t buffer_bytes) const { size_t pb = packed_bytes(); @@ -1229,6 +1276,9 @@ XrlAtom::pack(uint8_t* buffer, size_t buffer_bytes) const case xrlatom_uint64: packed_size += pack_uint64(buffer + packed_size); break; + case xrlatom_fp64: + packed_size += pack_fp64(buffer + packed_size); + break; // ... Your type here ... } @@ -1330,6 +1380,9 @@ XrlAtom::unpack(const uint8_t* buffer, size_t buffer_bytes) case xrlatom_uint64: used = unpack_uint64(buffer + unpacked); break; + case xrlatom_fp64: + used = unpack_fp64(buffer + unpacked); + break; // ... Your type here ... } diff --git a/xorp/libxipc/xrl_atom.hh b/xorp/libxipc/xrl_atom.hh index d4be38f..50fb4f1 100644 --- a/xorp/libxipc/xrl_atom.hh +++ b/xorp/libxipc/xrl_atom.hh @@ -39,6 +39,7 @@ #include "xrl_atom_list.hh" +#include "fp64.h" enum XrlAtomType { @@ -56,13 +57,14 @@ enum XrlAtomType { xrlatom_binary, xrlatom_int64, xrlatom_uint64, + xrlatom_fp64, // ... Your type's unique enumerated name here ... // Changing order above will break binary compatibility // ...Don't forget to update xrlatom_start and xrlatom_end below... // Bounds for enumerations xrlatom_start = xrlatom_int32, // First valid enumerated value - xrlatom_end = xrlatom_uint64 // Last valid enumerated value + xrlatom_end = xrlatom_fp64 // Last valid enumerated value }; inline XrlAtomType& operator++(XrlAtomType& t) @@ -329,6 +331,16 @@ public: } + // fp64 constructors + explicit XrlAtom(const fp64_t& value) + : _type(xrlatom_fp64), _have_data(true), _own(true), _u64val(value) {} + + XrlAtom(const char* name, fp64_t value) throw (BadName) + : _type(xrlatom_fp64), _have_data(true), _own(true), _fp64val(value) { + set_name(name); + } + + // ... Your type's constructors here ... // Copy operations @@ -368,6 +380,7 @@ public: const vector& binary() const throw (NoData, WrongType); const int64_t& int64() const throw (NoData, WrongType); const uint64_t& uint64() const throw (NoData, WrongType); + const fp64_t& fp64() const throw (NoData, WrongType); // ... Your type's accessor method here ... @@ -392,6 +405,7 @@ public: SET(string, _text, &) SET(XrlAtomList, _list, &) SET(vector, _binary, &); + SET(fp64_t, _fp64val, ) #undef SET void set(const IPv4& v) { @@ -446,6 +460,7 @@ private: size_t pack_list(uint8_t* buffer, size_t buffer_bytes) const; size_t pack_binary(uint8_t* buffer) const; size_t pack_uint64(uint8_t* buffer) const; + size_t pack_fp64(uint8_t* buffer) const; size_t unpack_name(const uint8_t* buffer, size_t buffer_bytes) throw (BadName); @@ -460,6 +475,7 @@ private: size_t unpack_list(const uint8_t* buffer, size_t buffer_bytes); size_t unpack_binary(const uint8_t* buffer, size_t buffer_bytes); size_t unpack_uint64(const uint8_t* buffer); + size_t unpack_fp64(const uint8_t* buffer); private: XrlAtomType _type; @@ -479,6 +495,7 @@ private: vector* _binary; int64_t _i64val; uint64_t _u64val; + fp64_t _fp64val; // ... Your type here, if it's more than sizeof(uintptr_t) bytes, // use a pointer ... diff --git a/xorp/rtrmgr/xorp_client.cc b/xorp/rtrmgr/xorp_client.cc index e4e01a8..5119ff4 100644 --- a/xorp/rtrmgr/xorp_client.cc +++ b/xorp/rtrmgr/xorp_client.cc @@ -143,6 +143,7 @@ XorpClient::fake_return_args(const string& xrl_return_spec) case xrlatom_binary: case xrlatom_uint64: case xrlatom_int64: + case xrlatom_fp64: XLOG_UNFINISHED(); break; } diff --git a/xorp/xrl/interfaces/test.xif b/xorp/xrl/interfaces/test.xif index b6e3fe9..bd84ad8 100644 --- a/xorp/xrl/interfaces/test.xif +++ b/xorp/xrl/interfaces/test.xif @@ -36,4 +36,9 @@ interface test/1.0 { * Something that always fails. */ shoot_foot; + + /** + * Handle IEEE754 binary64 format. + */ + float_my_point ? input:fp64 -> output:fp64; } diff --git a/xorp/xrl/scripts/Xif/xiftypes.py b/xorp/xrl/scripts/Xif/xiftypes.py index d8d6180..85489f2 100644 --- a/xorp/xrl/scripts/Xif/xiftypes.py +++ b/xorp/xrl/scripts/Xif/xiftypes.py @@ -12,7 +12,8 @@ xrl_atom_type = { 'list' : ('XrlAtomList', 'list', 'list'), 'binary' : ('vector', 'binary', 'binary'), 'i64' : ('int64_t', 'int64', 'i64'), - 'u64' : ('uint64_t', 'uint64', 'i64') + 'u64' : ('uint64_t', 'uint64', 'i64'), + 'fp64' : ('fp64_t', 'fp64', 'double') } class XrlArg: -- 1.7.4.1 From greearb at candelatech.com Wed Aug 31 08:18:54 2011 From: greearb at candelatech.com (Ben Greear) Date: Wed, 31 Aug 2011 08:18:54 -0700 Subject: [Xorp-hackers] [PATCH] Support for IEEE754 binary64 format in XRLs In-Reply-To: <1314791703-23416-1-git-send-email-ss@comp.lancs.ac.uk> References: <4E5CFAA3.6000603@comp.lancs.ac.uk> <1314791703-23416-1-git-send-email-ss@comp.lancs.ac.uk> Message-ID: <4E5E50DE.80802@candelatech.com> On 08/31/2011 04:55 AM, ss at comp.lancs.ac.uk wrote: > From: Steven Simpson See comments inline below. > diff --git a/xorp/libxipc/SConscript b/xorp/libxipc/SConscript > index 104bc8e..e7cf973 100644 > --- a/xorp/libxipc/SConscript > +++ b/xorp/libxipc/SConscript > @@ -87,6 +87,7 @@ libxipc_sources = [ > 'xrl_std_router.cc', > 'xrl_tokens.cc', > 'xuid.cc', # only for udp (and fea tcpudp mgr) > + 'fp64serial.c', > ] It should be a .cc file I think. > > # deal with shared objects > diff --git a/xorp/libxipc/fp64.h b/xorp/libxipc/fp64.h > new file mode 100644 > index 0000000..8e49a19 > --- /dev/null > +++ b/xorp/libxipc/fp64.h > @@ -0,0 +1,198 @@ > +// -*- c-basic-offset: 4; tab-width: 8; indent-tabs-mode: t -*- > +// vim:set sts=4 ts=8: > + > +// Copyright (c) 2001-2011 XORP, Inc and Others > +// > +// This program is free software; you can redistribute it and/or modify > +// it under the terms of the GNU Lesser General Public License, Version > +// 2.1, June 1999 as published by the Free Software Foundation. > +// Redistribution and/or modification of this program under the terms of > +// any other version of the GNU Lesser General Public License is not > +// permitted. > +// > +// This program is distributed in the hope that it will be useful, but > +// WITHOUT ANY WARRANTY; without even the implied warranty of > +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For more details, > +// see the GNU Lesser General Public License, Version 2.1, a copy of > +// which can be found in the XORP LICENSE.lgpl file. > +// > +// XORP, Inc, 2953 Bunker Hill Lane, Suite 204, Santa Clara, CA 95054, USA; > +// http://xorp.net > + > +// $XORP: xorp/libxipc/xrl_atom.hh,v 1.23 2008/10/30 20:49:07 pavlin Exp $ Please just remove the previous line. In general, I'm amazed at how much code this took, but from skimming through it quickly, I didn't notice any issues. I guess floating-point serialization is just a pain in the arse to do right! Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com