Re: Is this ground dead? Also, info on Mach that's more recent

Re: Is this ground dead? Also, info on Mach that's more recent

[Thomas G. McWilliams]

David A. Cuthbert <dacut@henry.ece.cmu.edu> wrote:
: At any rate, relying on type safety for protection means that you
: can't use C, C++, or assembly, or anything written in those
: languages (so forget device drivers).  Assembly is the killer here;

Have you used Ada?  Ada is type-safe and more powerful than C for
low level bit-twiddling. Ada is a natural for device drivers and
systems programming.

Re: Is this ground dead? Also, info on Mach that's more recent

[David A. Cuthbert]

Thomas G. McWilliams <tgm@netcom.com> wrote:
>David A. Cuthbert <dacut@henry.ece.cmu.edu> wrote:
>: At any rate, relying on type safety for protection means that you
>: can't use C, C++, or assembly, or anything written in those
>: languages (so forget device drivers).  Assembly is the killer here;
>
>Have you used Ada?  Ada is type-safe and more powerful than C for
>low level bit-twiddling. Ada is a natural for device drivers and
>systems programming.

Used, no; glanced at code samples, yes.  My impression is that it
looks rather neat (nicer than C++ in many respects), but I've invested
too much into my C++ tools to even consider a switch.

I'm somewhat confused as to how Ada can be "natural" for device
drivers and systems programming.  For example, how do I code a task
switch or set up a DMA channel to a device in Ada?  Relying on a
library written in anything but Ada doesn't count.

Of course, I have no idea how I'd do that in C or C++, either, without
relying on nasty tricks like relying on assumptions about the
compiler's code generation and purposely breaking the type system.

-- 
David A. Cuthbert (dacut@ece.cmu.edu)
Graduate Student    Electrical and Computer Engineering
Data Storage Systems Center, Carnegie Mellon University

Re: Is this ground dead? Also, info on Mach that's more recent

[Robert Dewar]

David says

<<I'm somewhat confused as to how Ada can be "natural" for device
drivers and systems programming.  For example, how do I code a task
switch or set up a DMA channel to a device in Ada?  Relying on a
library written in anything but Ada doesn't count.

Of course, I have no idea how I'd do that in C or C++, either, without
relying on nasty tricks like relying on assumptions about the
compiler's code generation and purposely breaking the type system.
>>

Well if you look at chapter 13 and annex C in the RM, you wlil find lots
of useful stuff for writing low level code, Ada is (perhaps surprisingly
to some) better equipped for low level programming of this kind than C
(for example, the ability to lay out records precisely by bit numbers,
the ability to define interrupt routines, the ability to specify where
in memory declared variables are located etc).

Of course at some level, you may need to escape into assembler in either
language. Here Ada again is ahead of C, a full implementation of Ada is
*required* to provide an escape to assembler (either with intrinsics or
with package machine_Code). Of course a C compiler *may* provide this
important capability, but an Ada compiler MUST provide it (if it fully
implements the language).

Re: Is this ground dead? Also, info on Mach that's more recent

[Anonymous]

<34AE2AE8.ED17B2C6@gildea.net>
<5lzpky66rq.fsf@tequila.systemsz.cs.yale.edu>
<69jr4q$44j$1@encore.ece.cmu.edu> <tgmEMy5z4.9vs@netcom.com>

On 17 Jan 1998 23:08:59 GMT, dacut@henry.ece.cmu.edu (David A. Cuthbert)
wrote:

> Thomas G. McWilliams <tgm@netcom.com> wrote:
> >David A. Cuthbert <dacut@henry.ece.cmu.edu> wrote:
> >: At any rate, relying on type safety for protection means that you
> >: can't use C, C++, or assembly, or anything written in those
> >: languages (so forget device drivers).  Assembly is the killer here;
> >
> >Have you used Ada?  Ada is type-safe and more powerful than C for
> >low level bit-twiddling. Ada is a natural for device drivers and
> >systems programming.
> 
> Used, no; glanced at code samples, yes.  My impression is that it
> looks rather neat (nicer than C++ in many respects), but I've invested
> too much into my C++ tools to even consider a switch.
> 
> I'm somewhat confused as to how Ada can be "natural" for device
> drivers and systems programming.  For example, how do I code a task
> switch or set up a DMA channel to a device in Ada?  Relying on a
> library written in anything but Ada doesn't count.
> 
> Of course, I have no idea how I'd do that in C or C++, either, without
> relying on nasty tricks like relying on assumptions about the
> compiler's code generation and purposely breaking the type system.
> 
> -- 
> David A. Cuthbert (dacut@ece.cmu.edu)
> Graduate Student    Electrical and Computer Engineering
> Data Storage Systems Center, Carnegie Mellon University
> 
> 

Sounds as if you should learn Ada. Ada has low-level features for
specifying where in memory variables reside and how they are
represented, which are missing from C/++, and is type safe and easier to
read than assembler.

Since tasking is part of Ada, one doesn't generally code task switches
explicitly in Ada. For other low-level operations, one generally does
not need to break the type system or rely on assumptions about the
compiler's code generation. Such operations are generally OS or hardware
dependent, so I do not exclude relying on the features of the OS or
hardware.

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"English bed-wetting types."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Re: Is this ground dead? Also, info on Mach that's more recent

[feladdress.peter]

Checking at compile time is to put a bucket under the hole
instead of fixing the leak!

Typechecking done by the compiler is (IMHO) the wrong place.
It should be done at link time (or load time) .

Typechecking at compile time will among other things create
awful code at those times where typechecking is not wanted.
(like printf() ) and does not really prevent one from
screwing up arguments under all circumstances.



Very few existing systems does this however...

Peter h

Anonymous <nobody@REPLAY.COM> wrote:
: <34AE2AE8.ED17B2C6@gildea.net>
: <5lzpky66rq.fsf@tequila.systemsz.cs.yale.edu>
: <69jr4q$44j$1@encore.ece.cmu.edu> <tgmEMy5z4.9vs@netcom.com>

: On 17 Jan 1998 23:08:59 GMT, dacut@henry.ece.cmu.edu (David A. Cuthbert)
: wrote:

: > Thomas G. McWilliams <tgm@netcom.com> wrote:
: > >David A. Cuthbert <dacut@henry.ece.cmu.edu> wrote:
: > >: At any rate, relying on type safety for protection means that you
: > >: can't use C, C++, or assembly, or anything written in those
: > >: languages (so forget device drivers).  Assembly is the killer here;
: > >
: > >Have you used Ada?  Ada is type-safe and more powerful than C for
: > >low level bit-twiddling. Ada is a natural for device drivers and
: > >systems programming.
: > 
: > Used, no; glanced at code samples, yes.  My impression is that it
: > looks rather neat (nicer than C++ in many respects), but I've invested
: > too much into my C++ tools to even consider a switch.
: > 
: > I'm somewhat confused as to how Ada can be "natural" for device
: > drivers and systems programming.  For example, how do I code a task
: > switch or set up a DMA channel to a device in Ada?  Relying on a
: > library written in anything but Ada doesn't count.
: > 
: > Of course, I have no idea how I'd do that in C or C++, either, without
: > relying on nasty tricks like relying on assumptions about the
: > compiler's code generation and purposely breaking the type system.
: > 
: > -- 
: > David A. Cuthbert (dacut@ece.cmu.edu)
: > Graduate Student    Electrical and Computer Engineering
: > Data Storage Systems Center, Carnegie Mellon University
: > 
: > 

: Sounds as if you should learn Ada. Ada has low-level features for
: specifying where in memory variables reside and how they are
: represented, which are missing from C/++, and is type safe and easier to
: read than assembler.

: Since tasking is part of Ada, one doesn't generally code task switches
: explicitly in Ada. For other low-level operations, one generally does
: not need to break the type system or rely on assumptions about the
: compiler's code generation. Such operations are generally OS or hardware
: dependent, so I do not exclude relying on the features of the OS or
: hardware.

: Jeff Carter  PGP:1024/440FBE21
: My real e-mail address: ( carter @ innocon . com )
: "English bed-wetting types."
: Monty Python & the Holy Grail

: Posted with Spam Hater - see
: http://www.compulink.co.uk/~net-services/spam/

-- 
I am truly sorry for my mungled mail address.
Please remove "feladdress" and change "at" to "@"
<feladress.peter at vtd.volvo.feladdress.se>
Peter H�kanson,Volvo Technological Development. Dep 6970,Gothenburg,Sweden

Re: Is this ground dead? Also, info on Mach that's more recent

[vonhend]

In <dewar.885087293@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>
>Well if you look at chapter 13 and annex C in the RM, you wlil find lots
>of useful stuff for writing low level code, Ada is (perhaps surprisingly
>to some) better equipped for low level programming of this kind than C
>(for example, the ability to lay out records precisely by bit numbers,
>the ability to define interrupt routines, the ability to specify where
>in memory declared variables are located etc).

The C language has provided a syntax for bit fields since the late 70's.
The disadvantage of C's syntax viz Ada's is that you have to explicitly
insert dummy fields in the record if you want non-contiguous fields.
Conversely, C lacks the strong type checking that can make it more
difficult to work with bit fields in Ada.  I write these lines based in
personal experience:  without careful type definition, unchecked conversions
become rampant when Ada is used at the bit level.
Mark Von Hendy
vonhend@ibm.net

Re: Is this ground dead? Also, info on Mach that's more recent

[Robert Dewar]

Mark said

<<The C language has provided a syntax for bit fields since the late 70's.
The disadvantage of C's syntax viz Ada's is that you have to explicitly
insert dummy fields in the record if you want non-contiguous fields.
Conversely, C lacks the strong type checking that can make it more
difficult to work with bit fields in Ada.  I write these lines based in
personal experience:  without careful type definition, unchecked conversions
become rampant when Ada is used at the bit level.
>>

The C facilities are far more primitive. In particular the bit fields in
C can only be applies to integral types (you cannot use them for float
types, or even for enumeration types). Yes, you can rig things up with
bit fields, but it is often complex and implementation dependent to do so.


As for what can happen without careful type definition, rampant unchecked
conversions are the least of the problems. If there is one place where
care is needed (and good training and design sense counts for a lot) it
is in proper design of types.

Properly written low level code in Ada is cleaner and easier to read
than corresponding low level code in C, for the simple reason that Ada
provides more extensive facilities in this area.

Re: Is this ground dead? Also, info on Mach that's more recent

[Robert Dewar]

Peter says

<<Checking at compile time is to put a bucket under the hole
instead of fixing the leak!

Typechecking done by the compiler is (IMHO) the wrong place.
It should be done at link time (or load time) .

Typechecking at compile time will among other things create
awful code at those times where typechecking is not wanted.
(like printf() ) and does not really prevent one from
screwing up arguments under all circumstances.
>>

Peter must I guess be a C programmer with very little imagination as
to what can and cannot be done by type checking. It is of course
perfectly possible to do thorough type checking at compile time (there
are many languages which show this, e.g. Algol-68 if you want to look
at structural typing, or Ada if you want to look at a more elaborate
typing scheme.

Of course type checking at compile time does not generate awful code?
What on earth are you talking about? The whole point of type checking
at compile time is that it generates NO CODE AT ALL!

As for printf, it is perfectly possible to design a formatted print
interface that is type safe, and no less efficient than printf, indeed
one generally would expect a formatted print facility to generate much
BETTER code than printf, precisely because printf has to do runtime
type checking by its very nature.

Peter, you have got things amazingly upside down here. It is almost
incredible that you can have things so precisely wrong! You really
should broaden your horizons and learn a little bit more about other
programming languages!

Re: Is this ground dead? Also, info on Mach that's more rec

[Jerry van Dijk]

In article <6a0351$i53@nike.volvo.se> feladdress.peter@vtd.volvo.feladdress.se writes:

>Typechecking done by the compiler is (IMHO) the wrong place.
>It should be done at link time (or load time) .

Hmmmm, I must be in the wrong news group, or something...

:-)

--

-- Jerry van Dijk | Leiden, Holland
-- Consultant     | Team Ada
-- Ordina Finance | jdijk@acm.org

Re: Is this ground dead? Also, info on Mach that's more recent

[Christopher Browne]

On 19 Jan 1998 17:39:45 GMT, feladdress.peter@vtd.volvo.feladdress.se
<feladdress.peter@vtd.volvo.feladdress.se> wrote: 
>
>Checking at compile time is to put a bucket under the hole
>instead of fixing the leak!
>
>Typechecking done by the compiler is (IMHO) the wrong place.
>It should be done at link time (or load time) .
>
>Typechecking at compile time will among other things create
>awful code at those times where typechecking is not wanted.
>(like printf() ) and does not really prevent one from
>screwing up arguments under all circumstances.

In the "real" world, things get messy, and it's expedient to solve
problems in varying ways depending on what methodology seems most
expedient.

Checking at compile time has the "advantage" that errors may be picked
up before users are ever exposed to the code.  For embedded systems,
this can be critical. 

Checking at run time (or link time or load time) puts the checking off;
if this results in the system being allowed into a dangerously
inconsistent state, this may prove unacceptable. 

Neither approach is perfect; they all have application... 

-- 
"We all know Linux is great...it does infinite loops in 5 seconds."
(Linus Torvalds about the superiority of Linux on the Amterdam Linux
Symposium) 
cbbrowne@hex.net -  <http://www.hex.net/~cbbrowne/lsf.html>

Compile-time type checking

[Nick Roberts]

What idiot was it who designed Ada to do compile-time type checking, eh? 
(Almost as daft as thinking the world isn't flat, really ;-)

Nick