* Re: Is this ground dead? Also, info on Mach that's more recent [not found] ` <69jr4q$44j$1@encore.ece.cmu.edu> @ 1998-01-17 0:00 ` Thomas G. McWilliams 1998-01-17 0:00 ` David A. Cuthbert 0 siblings, 1 reply; 11+ messages in thread From: Thomas G. McWilliams @ 1998-01-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Is this ground dead? Also, info on Mach that's more recent 1998-01-17 0:00 ` Is this ground dead? Also, info on Mach that's more recent Thomas G. McWilliams @ 1998-01-17 0:00 ` David A. Cuthbert 1998-01-17 0:00 ` Robert Dewar 1998-01-19 0:00 ` Anonymous 0 siblings, 2 replies; 11+ messages in thread From: David A. Cuthbert @ 1998-01-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Is this ground dead? Also, info on Mach that's more recent 1998-01-17 0:00 ` David A. Cuthbert @ 1998-01-17 0:00 ` Robert Dewar 1998-01-19 0:00 ` vonhend 1998-01-19 0:00 ` Anonymous 1 sibling, 1 reply; 11+ messages in thread From: Robert Dewar @ 1998-01-17 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Is this ground dead? Also, info on Mach that's more recent 1998-01-17 0:00 ` Robert Dewar @ 1998-01-19 0:00 ` vonhend 1998-01-19 0:00 ` Robert Dewar 0 siblings, 1 reply; 11+ messages in thread From: vonhend @ 1998-01-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Is this ground dead? Also, info on Mach that's more recent 1998-01-19 0:00 ` vonhend @ 1998-01-19 0:00 ` Robert Dewar 0 siblings, 0 replies; 11+ messages in thread From: Robert Dewar @ 1998-01-19 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Is this ground dead? Also, info on Mach that's more recent 1998-01-17 0:00 ` David A. Cuthbert 1998-01-17 0:00 ` Robert Dewar @ 1998-01-19 0:00 ` Anonymous 1998-01-19 0:00 ` feladdress.peter 1 sibling, 1 reply; 11+ messages in thread From: Anonymous @ 1998-01-19 0:00 UTC (permalink / raw) <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/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Is this ground dead? Also, info on Mach that's more recent 1998-01-19 0:00 ` Anonymous @ 1998-01-19 0:00 ` feladdress.peter 1998-01-19 0:00 ` Robert Dewar ` (3 more replies) 0 siblings, 4 replies; 11+ messages in thread From: feladdress.peter @ 1998-01-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Is this ground dead? Also, info on Mach that's more recent 1998-01-19 0:00 ` feladdress.peter @ 1998-01-19 0:00 ` Robert Dewar 1998-01-20 0:00 ` Is this ground dead? Also, info on Mach that's more rec Jerry van Dijk ` (2 subsequent siblings) 3 siblings, 0 replies; 11+ messages in thread From: Robert Dewar @ 1998-01-19 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Is this ground dead? Also, info on Mach that's more rec 1998-01-19 0:00 ` feladdress.peter 1998-01-19 0:00 ` Robert Dewar @ 1998-01-20 0:00 ` Jerry van Dijk 1998-01-20 0:00 ` Is this ground dead? Also, info on Mach that's more recent Christopher Browne 1998-01-22 0:00 ` Compile-time type checking Nick Roberts 3 siblings, 0 replies; 11+ messages in thread From: Jerry van Dijk @ 1998-01-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Is this ground dead? Also, info on Mach that's more recent 1998-01-19 0:00 ` feladdress.peter 1998-01-19 0:00 ` Robert Dewar 1998-01-20 0:00 ` Is this ground dead? Also, info on Mach that's more rec Jerry van Dijk @ 1998-01-20 0:00 ` Christopher Browne 1998-01-22 0:00 ` Compile-time type checking Nick Roberts 3 siblings, 0 replies; 11+ messages in thread From: Christopher Browne @ 1998-01-20 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Compile-time type checking 1998-01-19 0:00 ` feladdress.peter ` (2 preceding siblings ...) 1998-01-20 0:00 ` Is this ground dead? Also, info on Mach that's more recent Christopher Browne @ 1998-01-22 0:00 ` Nick Roberts 3 siblings, 0 replies; 11+ messages in thread From: Nick Roberts @ 1998-01-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~1998-01-22 0:00 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <34AE2AE8.ED17B2C6@gildea.net> [not found] ` <5l3eir6lvj.fsf@tequila.systemsz.cs.yale.edu> [not found] ` <69j8u6$spl$1@encore.ece.cmu.edu> [not found] ` <5lzpky66rq.fsf@tequila.systemsz.cs.yale.edu> [not found] ` <69jr4q$44j$1@encore.ece.cmu.edu> 1998-01-17 0:00 ` Is this ground dead? Also, info on Mach that's more recent Thomas G. McWilliams 1998-01-17 0:00 ` David A. Cuthbert 1998-01-17 0:00 ` Robert Dewar 1998-01-19 0:00 ` vonhend 1998-01-19 0:00 ` Robert Dewar 1998-01-19 0:00 ` Anonymous 1998-01-19 0:00 ` feladdress.peter 1998-01-19 0:00 ` Robert Dewar 1998-01-20 0:00 ` Is this ground dead? Also, info on Mach that's more rec Jerry van Dijk 1998-01-20 0:00 ` Is this ground dead? Also, info on Mach that's more recent Christopher Browne 1998-01-22 0:00 ` Compile-time type checking Nick Roberts
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox