| 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: CA V4 Protocol Specification |
| From: | Andrew Johnson <[email protected]> |
| To: | Jeff Hill <[email protected]> |
| Cc: | [email protected] |
| Date: | Wed, 26 Oct 2005 15:57:06 -0500 |
Jeff Hill wrote:
Attached is a rough cut at the EPICS V4 CA protocol specification.
Thanks Jeff.
PS: Andrew, its fine to put this up on the web / wiki if you would like.
Great, I've now done that. Could we make the wiki version the canonical one? It's a bit of a pain to convert as I've just discovered that the converter I use discards the content of any table cell that consists of just a numeric zero, so I had to add all your zero values back by hand (I hope I didn't miss any!).
A couple of comments on the simpler stuff early on:There is no single IEEE standard for a 128 bit float; there are many possible 128 bit formats that can all legitimately claim to fall into the IEEE754 category called Double Extended Precision. Your FLOAT128 doesn't specify which of these you'll be passing over the wire, although I realise that you're probably wanting to use what is commonly referred to as quadruple precision. RFC 1832 http://rfc.net/rfc1832.html#s3.8 defines this format for XDR, and I believe both 64-bit SPARC and PowerPC CPUs support it natively, and possibly other recent chips too.
The bit numbering in the UINTN tables is wrong. The general case should be that in Octet n (counting from 0), bits 6-0 contain bits n*7+6 thru n*7 of the unsigned value, i.e. successive octets will contain bits 6-0, 13-7, 20-14 etc.
Note that I have not made any changes in the Wiki version other than reformatting your distributed text.
- Andrew -- English probably arose from Normans trying to pick up Saxon girls.