[Caml-list] Suggestion for Int32.rotate

[Caml-list] Suggestion for Int32.rotate

[Berke Durak]

Hello,

I was attempting to implement some block ciphers, and I missed the following :

1) An Int32.rotate function that generates data-dependent
hardware rotates whenever possible (i.e. things like rol.l d0,d1)

2) A syntax extension (or extension to the standard syntax) for
entering Int32 and Int64 constants. 

3) A hack into Printf to remove the need to use Int32.format

I.e. better support for int32's. I understand that the Caml team does
not want people to use int32's (or int64's) by default. However a lot
of coding/crypto stuff, deserving to be ported to Caml, works with
32-bit ints and it would be good to be able to use them at full speed.

For example, the MD5 routine used in Digest.string could be efficiently
rewritten in Caml.
--
Berke


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Suggestion for Int32.rotate

[Xavier Leroy]

> 2) A syntax extension (or extension to the standard syntax) for
> entering Int32 and Int64 constants. 

This has been on my to do list for a while.  The main issue is finding
a decent syntax...  (All discussions on this list seem to converge on
syntax these days, that's awful :-) We have three "big integer" types:
int32, nativeint and int64.  A C-style syntax would be 12345L for
int32 and 123456789LL for int64; what about nativeint?  12345N ?
Anything nicer?

> 3) A hack into Printf to remove the need to use Int32.format

Printf support was added in 3.04: "%ld", "%nd", "%Ld" for int32,
nativeint and int64 respectively.

> I.e. better support for int32's. I understand that the Caml team does
> not want people to use int32's (or int64's) by default.

It's not that we object to this, just that these types are boxed and
this impacts performance to some extent, so you're advised to use them
only when you need them (as you obviously do).

> However a lot
> of coding/crypto stuff, deserving to be ported to Caml, works with
> 32-bit ints and it would be good to be able to use them at full speed.
> For example, the MD5 routine used in Digest.string could be efficiently
> rewritten in Caml.

I played with a Caml reimplementation of MD5 a while ago, and even
with various source-level tweaks, ocamlopt isn't clever enough to
eliminate all boxing and unboxing.  The result is about 2-3 times
slower than hand-optimized C.

More generally speaking, I don't think basic ciphers and hash
functions really benefit from being rewritten in Caml.  C is extremely
painful as a general-purpose language, but OK for some things:
bytecode interpreters, memory managers, device drivers, crypto
primitives, ...  MD5 written in Caml isn't noticeably nicer / safer /
less buggy than MD5 in C.  So, why not just interface with existing C
implementations -- with the additional benefits that someone else
already debugged and performance-tweaked them?

Don't get me wrong: as soon as we move up from the crypto basic
blocks into real cryptographic protocols and applications, the
benefits of Caml (or other high-level languages) become obvious.
(I shudder at the idea of implementing a public-key infrastructure in C.)
It's just that basic blocks like MD5 or DES are, well, just basic
blocks -- just like integer addition; who cares how they are implemented
as long as they work?

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Suggestion for Int32.rotate

[Daniel de Rauglaudre]

Hi,

On Wed, Feb 06, 2002 at 07:01:51PM +0100, Xavier Leroy wrote:

> A C-style syntax would be 12345L for int32 and 123456789LL for
> int64; what about nativeint?  12345N ?  Anything nicer?

This is nice. No lexing problem.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Suggestion for Int32.rotate

[Frederic van der Plancke]

Daniel de Rauglaudre wrote:
> 
> Hi,
> 
> On Wed, Feb 06, 2002 at 07:01:51PM +0100, Xavier Leroy wrote:
> 
> > A C-style syntax would be 12345L for int32 and 123456789LL for
> > int64; what about nativeint?  12345N ?  Anything nicer?
> 

A small problem of 12345L is that "L" for "long" is not justified on
64-bit platforms, and more importantly it is not at all obvious what
length it actually represents.

What about 12345i32, 123456789i64, like some C(++) compilers do; that would
preserve extensibility (in case one wants 123456789i128 in the future),
and makes the value types clearer and more consistent,
even though it makes the actual values somewhat less readable, specially
if one uses an uppercase I. ('N' or (why not) 'L' could be used instead.)
For native ints we could then chose either 12345i or 12345n. And keep
the other one for arbitrary-sized integers.

Just my €0.02 worth of suggestions... I can live with L and LL.

Frédéric vdP

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

[Caml-list] integer types and their literals

[james woodyatt]

On Wednesday, February 6, 2002, at 10:01 , Xavier Leroy wrote:
>                   [...] We have three "big integer" types:
> int32, nativeint and int64.  A C-style syntax would be 12345L for
> int32 and 123456789LL for int64; what about nativeint?  12345N ?
> Anything nicer?

Given my heritage as a Perl and C++ hacker, my opinion may be next to 
worthless here, so I will simply observe that this would be consistent 
with other choices already made, e.g. the syntax for representing 
integer literals in hexadecimal and octal.

I think what you have proposed here would do very well.


While we're on the subject:

It would be nice to have conversion functions that raise exceptions to 
indicate overflow, i.e. converting 0x100000000LL to int32 could raise an 
exception of int32, where the value is 0L.  Do you think such functions 
belong in the standard library, or should I expect to bolt them on later?

Also, I deeply long for unsigned integer types.  I'd be happy if the 
type system included them, and required explicit conversion between 
signed and unsigned integer values.  Is there a reason Ocaml doesn't 
have unsigned integer types?


--
j h woodyatt <jhw@wetware.com>
"...the antidote to misinformation is more information, not less."
                                                      --vinton cerf

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Suggestion for Int32.rotate

[Berke Durak]

On Wed, Feb 06, 2002 at 07:01:51PM +0100, Xavier Leroy wrote:
> > 2) A syntax extension (or extension to the standard syntax) for
> > entering Int32 and Int64 constants. 
> 
> This has been on my to do list for a while.  The main issue is finding
> a decent syntax...  (All discussions on this list seem to converge on
> syntax these days, that's awful :-) We have three "big integer" types:
> int32, nativeint and int64.  A C-style syntax would be 12345L for
> int32 and 123456789LL for int64; what about nativeint?  12345N ?
> Anything nicer?

I'd suggest lowercase 'l' for 32-bit and uppercase 'L' for 64-bit :

	0xffffffffl = -1	32-bit signed
	0xffffffffffffffffL = -1 (64-bit signed)
	1239884378742340923094029042n   bigint

Maybe 'z' instead of 'n' sound better ?

> > 3) A hack into Printf to remove the need to use Int32.format
> 
> Printf support was added in 3.04: "%ld", "%nd", "%Ld" for int32,
> nativeint and int64 respectively.

Wonderful, that's a good reason to upgrade.

[...]
> More generally speaking, I don't think basic ciphers and hash
> functions really benefit from being rewritten in Caml.
> [...] So, why not just interface with existing C
> implementations -- with the additional benefits that someone else
> already debugged and performance-tweaked them?

Granted that Caml doesn't make coding low-level cryptographic
primitives (at least, usual bit-fiddling ones) easier or safer.
However, when you want to implement a new crypto algorithm to do some
empirical cryptanalysis on it (statistical tests etc.) it's painful to
have to implement it in C, then interface C to Caml. I'd rather write
it directly in Caml. Being able to interface to C is an excellent
feature, but I'd also like to be able to do everything reasonably
efficiently in Caml. Further, if I write my algorithms in Caml, one
day if the compiler becomes smart enough it can be as efficient as C.

So, what about the rotate ?
-- 
Berke Durak
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Suggestion for Int32.rotate

[Chris Hecker]

>What about 12345i32, 123456789i64, like some C(++) compilers do; that would
>preserve extensibility (in case one wants 123456789i128 in the future),
>and makes the value types clearer and more consistent,
>even though it makes the actual values somewhat less readable, specially
>if one uses an uppercase I. ('N' or (why not) 'L' could be used instead.)
>For native ints we could then chose either 12345i or 12345n. And keep
>the other one for arbitrary-sized integers.

I agree with this.  Better to give absolute bit lengths in the syntax than to make more abbreviations.  But yes, 1234i32 is unreadable.  1234n32 is better.  1234N32 is okay as well.

>Just my €0.02 worth of suggestions... I can live with L and LL.

Same here about L and LL (worth $0.0173425 at today's rate).

Chris


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Suggestion for Int32.rotate

[Gerd Stolpmann]

On 2002.02.06 21:43 Frederic van der Plancke wrote:
> Daniel de Rauglaudre wrote:
> > 
> > Hi,
> > 
> > On Wed, Feb 06, 2002 at 07:01:51PM +0100, Xavier Leroy wrote:
> > 
> > > A C-style syntax would be 12345L for int32 and 123456789LL for
> > > int64; what about nativeint?  12345N ?  Anything nicer?
> > 
> 
> A small problem of 12345L is that "L" for "long" is not justified on
> 64-bit platforms, and more importantly it is not at all obvious what
> length it actually represents.
> 
> What about 12345i32, 123456789i64, like some C(++) compilers do; that would
> preserve extensibility (in case one wants 123456789i128 in the future),
> and makes the value types clearer and more consistent,
> even though it makes the actual values somewhat less readable, specially
> if one uses an uppercase I. ('N' or (why not) 'L' could be used instead.)
> For native ints we could then chose either 12345i or 12345n. And keep
> the other one for arbitrary-sized integers.

Why not allow "_" in integer literals, so one can write

12345_i32, 123456789_i64, 123_456_789_i64, 123456789_nat,
123456789_big (for bigints). I think this kind of suffix is easier
to remember than a single letter.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Suggestion for Int32.rotate

[Gerd Stolpmann]

On 2002.02.05 00:06 Berke Durak wrote:
> I.e. better support for int32's. I understand that the Caml team does
> not want people to use int32's (or int64's) by default. However a lot
> of coding/crypto stuff, deserving to be ported to Caml, works with
> 32-bit ints and it would be good to be able to use them at full speed.
> 
> For example, the MD5 routine used in Digest.string could be efficiently
> rewritten in Caml.

I have coded Blowfish and DES in Caml, and optimizing them is painful.
I would not do it again. Interestingly, Blowfish is faster if it uses
only int and not int32, although twice as many int operations are
needed than int32 operations.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Suggestion for Int32.rotate

[Brian Rogoff]

On Thu, 7 Feb 2002, Gerd Stolpmann wrote:
> Why not allow "_" in integer literals, so one can write
>
> 12345_i32, 123456789_i64, 123_456_789_i64, 123456789_nat,
> 123456789_big (for bigints). I think this kind of suffix is easier
> to remember than a single letter.

This looks like best suggestion yet, IMO.

-- Brian
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Suggestion for Int32.rotate

[Eric C. Cooper]

On Thu, Feb 07, 2002 at 02:07:35AM +0100, Gerd Stolpmann wrote:
> Why not allow "_" in integer literals, so one can write
> 
> 12345_i32, 123456789_i64, 123_456_789_i64, 123456789_nat,
> 123456789_big (for bigints). I think this kind of suffix is easier
> to remember than a single letter.

I like Gerd's suggestion.  Two others:

- Please support both signed and unsigned (or "int" and "card")
  literals of each width, perhaps using _s32 and _u32 etc.
  We would also need the unsigned analogs of Int32 and Int64 modules.

- Slightly off-topic: add hexadecimal character literals '\0xNN' At
  least once a year, I assume that '\010' should be *octal* 10, like
  in C.  Since you can't fix that without breaking old code, it would
  be nice to have the option of using hex char literals in new code.

Of course the meta-solution would be for Daniel to give us an
extensible lexer. :-)

-- 
Eric C. Cooper          e c c @ c m u . e d u
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Suggestion for Int32.rotate

[Thorsten Ohl]

Gerd Stolpmann writes:

> Why not allow "_" in integer literals, so one can write

That's the best solution.  Others have noticed this before, but let me
suggest to do the same for float literals.
-- 
Thorsten Ohl, Physics Department, TU Darmstadt -- ohl@hep.tu-darmstadt.de
http://heplix.ikp.physik.tu-darmstadt.de/~ohl/ [<=== PGP public key here]
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Suggestion for Int32.rotate

[Remi VANICAT]

Thorsten Ohl <ohl@hep.tu-darmstadt.de> writes:

> Gerd Stolpmann writes:
> 
> > Why not allow "_" in integer literals, so one can write
> 
> That's the best solution.  Others have noticed this before, but let me
> suggest to do the same for float literals.

it's already done in the cvs :

moi@debian:~/prog/ocaml-cvs/bin$ ./ocaml
        Objective Caml version 3.04+6 (2002-02-05)

# 123_345.56;;
- : float = 123345.56
# 123_465;;
- : int = 123465


-- 
Rémi Vanicat
vanicat@labri.u-bordeaux.fr
http://dept-info.labri.u-bordeaux.fr/~vanicat
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] More syntax: _ in numbers, backquote infix op's

[Christian Lindig]

On Thu, Feb 07, 2002 at 02:55:09PM +0100, Remi VANICAT wrote:
> Thorsten Ohl <ohl@hep.tu-darmstadt.de> writes:
> > Gerd Stolpmann writes:
> > > Why not allow "_" in integer literals, so one can write
> it's already done in the cvs :
> [..]
>         Objective Caml version 3.04+6 (2002-02-05)
> 
> # 123_345.56;;
> - : float = 123345.56
> # 123_465;;
> - : int = 123465

On a similar note, is there a chance we get Haskell-style infix
operators back? They allow to use a binary function add in infix
notation with backqotes: 3 `add` 4. This addition to the lexer was for a
short time in the repository, but taken out again:

    @@ -311,9 +311,6 @@ rule token = parse
                 { INFIXOP4(Lexing.lexeme lexbuf) }
       | ['*' '/' '%'] symbolchar *
                 { INFIXOP3(Lexing.lexeme lexbuf) }
    -  | "`" lowercase identchar * "`"
    -            { let s = Lexing.lexeme lexbuf in
    -              INFIXOP3(String.sub s 1 (String.length s - 2)) }
       | eof { EOF }
       | _
           { raise (Error(Illegal_character ((Lexing.lexeme lexbuf).[0]),

Are there ambiguities in the lexer?

-- Christian
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr