Loading ...
Sorry, an error occurred while loading the content.

SARITH project history [long]

Expand Messages
  • geldridg@progsoc.uts.edu.au
    -- another long message .. Thanks to Greg and Patrick for their recent discussion (30 Jan 2001) relating to the SARITH (Safe ARITHmetic) project:
    Message 1 of 3 , Jan 30, 2001
    View Source
    • 0 Attachment
      -- another long message ..

      Thanks to Greg and Patrick for their recent discussion (30 Jan 2001)
      relating to the SARITH (Safe ARITHmetic) project:

      http://groups.yahoo.com/group/smalleiffel/message/2992 - Greg
      http://groups.yahoo.com/group/smalleiffel/message/2993 - Patrick

      in which Patrick wrote in response to Greg:

      --8<--
      Greg C wrote:

      > I've been thinking about the integer representation problem. I also
      > took a look at the SARITH spec that was floating around last year. The
      > problem I have with SARITH is that it starts to get complicated and
      > ugly when Eiffel tries to mirror all of the permutations of integer
      > types available in C.

      Personally, I think SARITH handles integer types better than C. They have
      really thought about all the consequences of combining different kinds of
      integers, and they always do the right (intuitive) thing. AFAIK, this is
      a first! :-)

      Plus, if you want efficient unchecked versions, as provided with C,
      they're still there.
      -->8--

      For those interested on the details of the SARITH Project, take a look
      starting here:

      http://www.elj.com/open-source/sarith/sarith.html
      http://www.elj.com/open-source/sarith/history.txt

      The project is currently stalled as the key player in the project (dd)
      had to find a new job after the dotcom stock market meltdown in early
      2000. Guus also got busy in his job (70 hour weeks) and I did not have
      enough skills (still don't) to do the necessary work.

      The status of the project as of April 2000 is described in detail here:

      http://groups.yahoo.com/group/sarith/message/211

      In summary, Guus had the following classes fundamentally integrated
      into the SE distribution of the time (-0.77beta4):

      INTEGER_08, INTEGER_16, INTEGER_32 and
      UNSIGNED_INTEGER_08, UNSIGNED_INTEGER_16, UNSIGNED_INTEGER_32.

      See messages:

      http://groups.yahoo.com/group/sarith/message/161
      http://groups.yahoo.com/group/sarith/message/160

      However, there were some unresolved issues relating to the use of these
      new classes as generic parameters:

      http://groups.yahoo.com/group/sarith/message/180
      http://groups.yahoo.com/group/sarith/message/203

      Daniel had also done a lot coding on the C/assembler side of things:

      http://www.elj.com/open-source/sarith/download/
      -- sarith_upd_20000127.zip 30-Jan-2000 17:46 23k

      This was the first step and there was much more to be done:

      http://www.elj.com/open-source/sarith/sarith.html#work-to-be-done

      --8<--
      Modifications to the SmallEiffel source in order to:

      [* Create 8-, 16-, 32-bit signed and unsigned types ]
      [ -- done as described above ]

      * Stick them in class structs, mindful of alignment issues

      * Implement new promotional chart for the balancing rules

      * Add keywords "signed", "unsigned", "saturable", "critical", etc. that
      simply boil down to selecting an appropriate class, so as to not have
      to manually instantiate cryptically named types.

      * Testing

      Low-level coding:

      * Porting vc5 code to lcc-win32 (and other compilers?)
      -- dd seemed quite excited by Jacob's note on intrinsics:
      -- http://groups.yahoo.com/group/sarith/message/209
      -- I also summarised some recent posts from the comp.compilers.lcc
      -- newsgroups in relation lcc-win32 and inline assembler:
      -- http://groups.yahoo.com/group/elj-win32-dev/message/449

      * porting assembly code to other CPU's (DSP's?)

      * Multiplication, division, modulo, left- and right-shift
      saturable floating-point types

      * 2, 4 and 8-pack types

      * SUID probing once on boot function for class ANY or APPLICATION
      MMX, SSI/3DNow! interfaces
      -->8--

      The ideas behind SARITH went beyond classic Eiffel and it would be
      difficult to get enough support for it to be incorporated into the
      SE distribution. Therefore it was always going to be hard to support
      and keep uptodate with the current official SE distribution.

      Anyway, hope this help give some background to the SARITH project.
      It was a great project to be involved in and it even pushed (I think)
      Bertrand Meyer to quantify some ideas that might find its way into the
      next version of the language standard:

      http://groups.yahoo.com/group/sarith/message/181

      Maybe one day someone will take up the ball again .. Guus ?

      Geoff

      -- geoff@...
      -- http://www.elj.com/elj-daily.cgi

      ========================================================================

      A copy of the message announcing SARITH to the SmallEiffel mailing list:

      --8<--
      http://groups.yahoo.com/group/smalleiffel/message/1345

      From: Geoff Eldridge <geldridg@p...>
      Date: Fri Feb 4, 2000 2:39am
      Subject: [Ann/Update] SARITH: Safe/Saturating ARITHmetic

      SARITH (Safe/Saturating ARITHmetic) is an open-source project to provide
      new handling in Eiffel for 8-, 16-, 32-bit integer types, both signed and
      unsigned. Combinations of modulo- and saturation-arithmetic, as well as
      execution-halting behaviour on overflow/out-of-boundary assignment via
      require clauses, and exception-raising behaviours on both -debug and
      -boost compilation modes will be provided via class-types.

      The project is open-source'd (Eiffel Forum Freeware License, version 1),
      and although it is presently intended for an upcoming elj-win32
      test-release, use of the sources by other Eiffel compiler vendors, or
      ports to other languages, are hereby formally granted and welcome.

      Saturation ARITHmetic is applicable in any area of the problem domain
      where the size of numerical representation is critical, the limit of
      numerical representation is conceivably within reach, and where a closest
      representable value in the result is preferable to a "wrap-around" result.
      It is certainly not new: Ada is an example of a high-level language that
      implements saturation; and a good example of saturation support in
      hardware comes with MMX.

      SARITH, however, goes far beyond Ada or MMX, in that, probably for the
      first time in CS history, arbitrary mixtures of signed and unsigned types
      in both inputs and outputs are allowed, defined, and working correctly.
      Adding a signed and an unsigned, and saturating the result to an unsigned
      is permitted, for example. Mixed signed and unsigned types are allowed in
      all operations: addition and subtraction, assignments, relational
      comparators, etc.

      If, say, for an 8-bit example, p is signed 0x99 (a negative hex value) and
      q is unsigned 0x99 (a larger, positive hex value), p = q returns False,
      and p < q returns True.

      Safe ARITHmetic is the natural complement to saturation arithmetic. It is
      applicable most typically (though not always) to situations of the problem
      domain where "an overflow IS a bug"; --i.e.: where we want to *detect*
      rather than "adjust for" overflows.

      A future goal of SARITH is to bring MMX support to the Eiffel language.
      Unlike previous (inelegant) attempts to bring SIMD support to high level
      languages, SARITH aims to first support saturation and other behaviours
      with non-SIMD types, so as to "pave a road" to MMX in particular, and to
      SIMD more generally.

      The current status of SARITH is:

      * 8, 16, 32-bit signed and unsigned base types have been implemented
      at compiler level (these have been integrated into the -0.77beta6
      release).

      Not yet integrated in the compiler mods:

      * Inter-type casting/saturating assignments, mixed types and sizes
      (C macros).

      * Relational comparisions, mixed types allowed (C macros).

      * Addition/subtraction, mixed types, saturating and modulo (inline
      assembly, x86).

      Everything so far is 100% tested (for all possible input value
      combinations).

      Please note that SARITH is optimized for speed, by inlining, and by
      minimizing of register usage and branch prediction cache pollution;

      --code size concerns were last in the list.

      We are looking for support for the SARITH project and would welcome
      people with expertise in areas to help progress SARITH.

      SARITH related links:

      * Homepage:
      http://www.elj.com/open-source/sarith/

      * Mailing List:
      http://www.egroups.com/group/sarith/

      * Latest News:
      http://www.elj.com/open-source/sarith/news/
      http://www.elj.com/open-source/sarith/news/20000201.html

      * History:
      http://www.elj.com/open-source/sarith/history.txt

      * Downloads:
      http://www.elj.com/open-source/sarith/download/

      * ETL3: Conformance and Conversion
      http://www.egroups.com/group/sarith/181.html

      * SmallEiffel upgrade patch instructions and results
      http://www.egroups.com/group/sarith/161.html
      http://www.egroups.com/group/sarith/160.html

      Enjoy, from the Sarith Team.

      Daniel Watkins - Guus Leeuw - Geoff Eldridge
      dd@a... - guus.leeuw@t... - geoff@e...
      -->8--
      ========================================================================
    • Patrick Doyle
      ... What are the alignment issues? The C compiler will make sure things are aligned properly. Is that not enough? -- Patrick Doyle doylep@eecg.utoronto.ca
      Message 2 of 3 , Jan 31, 2001
      View Source
      • 0 Attachment
        geldridg@... wrote:

        > * Stick them in class structs, mindful of alignment issues

        What are the alignment issues? The C compiler will make sure things are
        aligned properly. Is that not enough?

        --
        Patrick Doyle
        doylep@...
      • Dipl.-Inf. Guus Leeuw jr.
        Oops :) I ve just stumbled over this message *rofl* Uhm? Ball? Picking it up? huh? *hehe* Yeah Yeah... I should, shouldn t I? Let s take steps one at a time.
        Message 3 of 3 , Feb 27, 2001
        View Source
        • 0 Attachment
          Oops :)

          I've just stumbled over this message *rofl*

          Uhm? Ball? Picking it up? huh? *hehe*

          Yeah Yeah... I should, shouldn't I?

          Let's take steps one at a time.
          I'll start with, what we call, planning :))))

          End of this month I'll be moving house to a city near
          Frankfurt. After that, I should be able to spend some time
          on the issues left open, I think I still know enough to put
          my brain back on it again.

          Not that my job's not busy (got busier), but my job involves
          me living in Cologne, where my project will be --> More time
          to spent on my machine during the evenings :)

          Let's wait a month and see where we are heading for. Be patient,
          but don't hold your breath :)

          > -----Original Message-----
          > From: geldridg@...
          > [mailto:geldridg@...]
          > Sent: Wednesday, January 31, 2001 8:49 AM
          > To: smalleiffel@...
          > Cc: sarith@yahoogroups.com
          > Subject: [sarith] SARITH project history [long]
          >
          >
          > -- another long message ..
          >
          > Thanks to Greg and Patrick for their recent discussion (30 Jan 2001)
          > relating to the SARITH (Safe ARITHmetic) project:
          >
          > http://groups.yahoo.com/group/smalleiffel/message/2992 - Greg
          > http://groups.yahoo.com/group/smalleiffel/message/2993 - Patrick
          >
          > in which Patrick wrote in response to Greg:
          >
          > --8<--
          > Greg C wrote:
          >
          > > I've been thinking about the integer representation problem. I also
          > > took a look at the SARITH spec that was floating around
          > last year. The
          > > problem I have with SARITH is that it starts to get complicated and
          > > ugly when Eiffel tries to mirror all of the permutations of integer
          > > types available in C.
          >
          > Personally, I think SARITH handles integer types better than
          > C. They have
          > really thought about all the consequences of combining
          > different kinds of
          > integers, and they always do the right (intuitive) thing.
          > AFAIK, this is
          > a first! :-)
          >
          > Plus, if you want efficient unchecked versions, as provided with C,
          > they're still there.
          > -->8--
          >
          > For those interested on the details of the SARITH Project,
          > take a look
          > starting here:
          >
          > http://www.elj.com/open-source/sarith/sarith.html
          > http://www.elj.com/open-source/sarith/history.txt
          >
          > The project is currently stalled as the key player in the
          > project (dd)
          > had to find a new job after the dotcom stock market meltdown in early
          > 2000. Guus also got busy in his job (70 hour weeks) and I
          > did not have
          > enough skills (still don't) to do the necessary work.
          >
          > The status of the project as of April 2000 is described in
          > detail here:
          >
          > http://groups.yahoo.com/group/sarith/message/211
          >
          > In summary, Guus had the following classes fundamentally integrated
          > into the SE distribution of the time (-0.77beta4):
          >
          > INTEGER_08, INTEGER_16, INTEGER_32 and
          > UNSIGNED_INTEGER_08, UNSIGNED_INTEGER_16, UNSIGNED_INTEGER_32.
          >
          > See messages:
          >
          > http://groups.yahoo.com/group/sarith/message/161
          > http://groups.yahoo.com/group/sarith/message/160
          >
          > However, there were some unresolved issues relating to the
          > use of these
          > new classes as generic parameters:
          >
          > http://groups.yahoo.com/group/sarith/message/180
          > http://groups.yahoo.com/group/sarith/message/203
          >
          > Daniel had also done a lot coding on the C/assembler side of things:
          >
          > http://www.elj.com/open-source/sarith/download/
          > -- sarith_upd_20000127.zip 30-Jan-2000 17:46 23k
          >
          > This was the first step and there was much more to be done:
          >
          > http://www.elj.com/open-source/sarith/sarith.html#work-to-be-done
          >
          > --8<--
          > Modifications to the SmallEiffel source in order to:
          >
          > [* Create 8-, 16-, 32-bit signed and unsigned types ]
          > [ -- done as described above ]
          >
          > * Stick them in class structs, mindful of alignment issues
          >
          > * Implement new promotional chart for the balancing rules
          >
          > * Add keywords "signed", "unsigned", "saturable",
          > "critical", etc. that
          > simply boil down to selecting an appropriate class, so as
          > to not have
          > to manually instantiate cryptically named types.
          >
          > * Testing
          >
          > Low-level coding:
          >
          > * Porting vc5 code to lcc-win32 (and other compilers?)
          > -- dd seemed quite excited by Jacob's note on intrinsics:
          > -- http://groups.yahoo.com/group/sarith/message/209
          > -- I also summarised some recent posts from the comp.compilers.lcc
          > -- newsgroups in relation lcc-win32 and inline assembler:
          > -- http://groups.yahoo.com/group/elj-win32-dev/message/449
          >
          > * porting assembly code to other CPU's (DSP's?)
          >
          > * Multiplication, division, modulo, left- and right-shift
          > saturable floating-point types
          >
          > * 2, 4 and 8-pack types
          >
          > * SUID probing once on boot function for class ANY or APPLICATION
          > MMX, SSI/3DNow! interfaces
          > -->8--
          >
          > The ideas behind SARITH went beyond classic Eiffel and it would be
          > difficult to get enough support for it to be incorporated into the
          > SE distribution. Therefore it was always going to be hard to support
          > and keep uptodate with the current official SE distribution.
          >
          > Anyway, hope this help give some background to the SARITH project.
          > It was a great project to be involved in and it even pushed (I think)
          > Bertrand Meyer to quantify some ideas that might find its
          > way into the
          > next version of the language standard:
          >
          > http://groups.yahoo.com/group/sarith/message/181
          >
          > Maybe one day someone will take up the ball again .. Guus ?
          >
          > Geoff
          >
          > -- geoff@...
          > -- http://www.elj.com/elj-daily.cgi
          >
          > =============================================================
          > ===========
          >
          > A copy of the message announcing SARITH to the SmallEiffel
          > mailing list:
          >
          > --8<--
          > http://groups.yahoo.com/group/smalleiffel/message/1345
          >
          > From: Geoff Eldridge <geldridg@p...>
          > Date: Fri Feb 4, 2000 2:39am
          > Subject: [Ann/Update] SARITH: Safe/Saturating ARITHmetic
          >
          > SARITH (Safe/Saturating ARITHmetic) is an open-source
          > project to provide
          > new handling in Eiffel for 8-, 16-, 32-bit integer types,
          > both signed and
          > unsigned. Combinations of modulo- and saturation-arithmetic,
          > as well as
          > execution-halting behaviour on overflow/out-of-boundary
          > assignment via
          > require clauses, and exception-raising behaviours on both -debug and
          > -boost compilation modes will be provided via class-types.
          >
          > The project is open-source'd (Eiffel Forum Freeware License,
          > version 1),
          > and although it is presently intended for an upcoming elj-win32
          > test-release, use of the sources by other Eiffel compiler vendors, or
          > ports to other languages, are hereby formally granted and welcome.
          >
          > Saturation ARITHmetic is applicable in any area of the
          > problem domain
          > where the size of numerical representation is critical, the limit of
          > numerical representation is conceivably within reach, and
          > where a closest
          > representable value in the result is preferable to a
          > "wrap-around" result.
          > It is certainly not new: Ada is an example of a high-level
          > language that
          > implements saturation; and a good example of saturation support in
          > hardware comes with MMX.
          >
          > SARITH, however, goes far beyond Ada or MMX, in that,
          > probably for the
          > first time in CS history, arbitrary mixtures of signed and
          > unsigned types
          > in both inputs and outputs are allowed, defined, and working
          > correctly.
          > Adding a signed and an unsigned, and saturating the result
          > to an unsigned
          > is permitted, for example. Mixed signed and unsigned types
          > are allowed in
          > all operations: addition and subtraction, assignments, relational
          > comparators, etc.
          >
          > If, say, for an 8-bit example, p is signed 0x99 (a negative
          > hex value) and
          > q is unsigned 0x99 (a larger, positive hex value), p = q
          > returns False,
          > and p < q returns True.
          >
          > Safe ARITHmetic is the natural complement to saturation
          > arithmetic. It is
          > applicable most typically (though not always) to situations
          > of the problem
          > domain where "an overflow IS a bug"; --i.e.: where we want
          > to *detect*
          > rather than "adjust for" overflows.
          >
          > A future goal of SARITH is to bring MMX support to the
          > Eiffel language.
          > Unlike previous (inelegant) attempts to bring SIMD support
          > to high level
          > languages, SARITH aims to first support saturation and other
          > behaviours
          > with non-SIMD types, so as to "pave a road" to MMX in
          > particular, and to
          > SIMD more generally.
          >
          > The current status of SARITH is:
          >
          > * 8, 16, 32-bit signed and unsigned base types have been implemented
          > at compiler level (these have been integrated into the -0.77beta6
          > release).
          >
          > Not yet integrated in the compiler mods:
          >
          > * Inter-type casting/saturating assignments, mixed types and sizes
          > (C macros).
          >
          > * Relational comparisions, mixed types allowed (C macros).
          >
          > * Addition/subtraction, mixed types, saturating and modulo (inline
          > assembly, x86).
          >
          > Everything so far is 100% tested (for all possible input value
          > combinations).
          >
          > Please note that SARITH is optimized for speed, by inlining, and by
          > minimizing of register usage and branch prediction cache pollution;
          >
          > --code size concerns were last in the list.
          >
          > We are looking for support for the SARITH project and would welcome
          > people with expertise in areas to help progress SARITH.
          >
          > SARITH related links:
          >
          > * Homepage:
          > http://www.elj.com/open-source/sarith/
          >
          > * Mailing List:
          > http://www.egroups.com/group/sarith/
          >
          > * Latest News:
          > http://www.elj.com/open-source/sarith/news/
          > http://www.elj.com/open-source/sarith/news/20000201.html
          >
          > * History:
          > http://www.elj.com/open-source/sarith/history.txt
          >
          > * Downloads:
          > http://www.elj.com/open-source/sarith/download/
          >
          > * ETL3: Conformance and Conversion
          > http://www.egroups.com/group/sarith/181.html
          >
          > * SmallEiffel upgrade patch instructions and results
          > http://www.egroups.com/group/sarith/161.html
          > http://www.egroups.com/group/sarith/160.html
          >
          > Enjoy, from the Sarith Team.
          >
          > Daniel Watkins - Guus Leeuw - Geoff Eldridge
          > dd@a... - guus.leeuw@t... - geoff@e...
          > -->8--
          > =============================================================
          > ===========
          >
          > ------------------------ Yahoo! Groups Sponsor
          > ---------------------~-~>
          > eGroups is now Yahoo! Groups
          > Click here for more details
          > http://click.egroups.com/1/11231/0/_/275865/_/980927368/
          > -------------------------------------------------------------
          > --------_->
          >
          > -------------------------------------------------------
          >
          > To Post a message, send it to: sarith@...
          >
          > To Unsubscribe, send a blank message to:
          > sarith-unsubscribe@...
          >
          > SARITH Homepage: http://www.elj.com/open-source/sarith/
          >
          > -------------------------------------------------------
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.