From: Sven Luther <sven.luther@wanadoo.fr>
To: caml-list@yquem.inria.fr, sven.luther@wanadoo.fr
Subject: ocaml, int32/64, bigarray and unsigned values ...
Date: Mon, 11 Apr 2005 09:46:19 +0200 [thread overview]
Message-ID: <20050411074619.GA26797@pegasos> (raw)
Hello,
I had plans to do a rewrite of GNU parted, a project which i am involved with,
in ocaml, and am being blocked by a few issues.
I know i can read disk sectors easily with the large-file support, which would
mean that i could support all underlying files that the ocaml standard library
supports, as opposed to parted which has some special code for linux, hurd,
and a couple of others. This would probably mean that if i did it right, i
could even use said library on windows, haven't investigated though.
Now to my problems, which are basically two.
1) most disk partition tables and filesystem have a mapping from a given
disk 512 byte sector to a descriptive structure. In C you simply define the
structure which corresponds to it, and you cast the sector to it, and then
test if some magic numbers and checksums are or not enough to identify the
sector as of the given type. The nearest to that would be either trying to
use the bigarray infrastructure and mmap capability, but it only makes
provision for mapping arrays and not structures. The other possibilities is
to either have some C bindings which do the proper cast, or to have access
functions which transform parts of a byte array into values. The first one
is ugly, as i was aiming for a purely ocaml solution (so i can build and
arch/plateform independent bytecode tool), and the second would probably be
a disaster speed wise, and also somewhat ugly unless properly encapsulated
in an abstract module.
Which brings me to the second problem.
2) Disk descriptors like partition table and filesystems, need to have exact
values, and the values are mostly unsigned 8, 16, 32 or 64 bit integers,
strings and bit fields. The int64 and int32 offer these kind of values, but
only the signed version. Is it save to make calculation on a signed number
and ignoring the sign bit ? Does this not cause risk of overflow ? I am not
particularly knowledgeable of the different signed/unsigned implementations
on the different architectures and plateform that i would need to support.
Also, i believe that bit fields are not easily available, altough there is
some support in the Int32 and int64 bit-wise operators, but again we have
the signed vs unsigned problem, altough it is maybe ignored for bit
operations ?
These two questions also are of importance if you want to write chip drivers
in ocaml, since you have to mmap the mmio registers of the chips, and have a
similar exact access to the registers used, altough the registers should fall
better in the bigarray mapping, since you mostly access those as 8, 16, 32, 64
or even 128 bit values.
But maybe ocaml 3.09 could have direct support for these kind of operations,
opening a new field of usage for ocaml ?
Friendly,
Sven Luther
next reply other threads:[~2005-04-11 7:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-11 7:46 Sven Luther [this message]
2005-04-11 12:57 ` [Caml-list] " Eric Cooper
2005-04-11 15:35 ` Sven Luther
2005-04-11 16:13 ` Eric Cooper
2005-04-13 6:54 ` Florian Hars
2005-04-13 18:28 ` Ken Rose
2005-05-25 6:06 ` partition tables and ocaml Taras
2005-05-25 9:09 ` Sven Luther
2005-04-12 17:19 ` [Caml-list] ocaml, int32/64, bigarray and unsigned values Paul Snively
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050411074619.GA26797@pegasos \
--to=sven.luther@wanadoo.fr \
--cc=caml-list@yquem.inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox