* Ada 95 based RTOS @ 2000-02-18 0:00 xaplos 2000-02-18 0:00 ` Tucker Taft 0 siblings, 1 reply; 42+ messages in thread From: xaplos @ 2000-02-18 0:00 UTC (permalink / raw) I am aware of several commercial products integrating Ada with C/C++ based RTOS, but is there any open-source RTOS that is completely written with the Ada programming language - from the hardware-specific kernel all the way to the GUI. I appologize for posting twice: this message and one to a non-related thread [Ada95-Compiler Recommendation for Win32]. - Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Ada 95 based RTOS 2000-02-18 0:00 Ada 95 based RTOS xaplos @ 2000-02-18 0:00 ` Tucker Taft 2000-02-21 0:00 ` xaplos 0 siblings, 1 reply; 42+ messages in thread From: Tucker Taft @ 2000-02-18 0:00 UTC (permalink / raw) xaplos@my-deja.com wrote: > > I am aware of several commercial products integrating Ada with C/C++ > based RTOS, but is there any open-source RTOS that is completely written > with the Ada programming language - from the hardware-specific kernel > all the way to the GUI. RTEMS is an RTOS written in Ada, though I don't believe it contains a GUI (I don't usually associate GUI's with RTOS's, though I guess that is changing...). I'm not certain whether RTEMS is open source. It is available integrated with GNAT. There are also Ada run-times that are written entirely in Ada from several of the Ada vendors (e.g. Aonix, DDC-I, Rational, Green Hills GNAT, etc.). (NOTE: Some of these are subset Ada run-times designed for safety-critical systems.) An Ada run-time system is effectively a special purpose RTOS. Many vendors make the source code for their Ada run-time system available to licensees of their compiler, though it may be an extra cost item. > > I appologize for posting twice: this message and one to a non-related > thread [Ada95-Compiler Recommendation for Win32]. > > - > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Ada 95 based RTOS 2000-02-18 0:00 ` Tucker Taft @ 2000-02-21 0:00 ` xaplos 2000-02-22 0:00 ` Matthew Majka 0 siblings, 1 reply; 42+ messages in thread From: xaplos @ 2000-02-21 0:00 UTC (permalink / raw) Thank you very much for the reference to RTEMS. I downloaded version 4 only to find out that the source files are in C. I keep reading on several sites that there is a version of RTEMS written in Ada; however, I can't find it. It is my understanding that I can compile Ada source into object files with GNAT and link them with RTEMS which is written in C to run my applications on lets say an M68K. Because of the nature of the project I'm working on - master's thesis - I'd really like to be working with code from the same language - hence my desire to find the Ada version of RTEMS. In article <38ADCA44.3B91BF6F@averstar.com>, Tucker Taft <stt@averstar.com> wrote: > xaplos@my-deja.com wrote: > > > > I am aware of several commercial products integrating Ada with C/C++ > > based RTOS, but is there any open-source RTOS that is completely written > > with the Ada programming language - from the hardware-specific kernel > > all the way to the GUI. > > RTEMS is an RTOS written in Ada, though I don't believe it contains > a GUI (I don't usually associate GUI's with RTOS's, though I guess > that is changing...). I'm not certain whether RTEMS is open source. > It is available integrated with GNAT. > > There are also Ada run-times that are written entirely in Ada from > several of the Ada vendors (e.g. Aonix, DDC-I, Rational, Green Hills > GNAT, etc.). (NOTE: Some of these are subset Ada run-times designed for > safety-critical systems.) > > An Ada run-time system is effectively a special purpose RTOS. Many > vendors make the source code for their Ada run-time system available > to licensees of their compiler, though it may be an extra cost item. > > > > > I appologize for posting twice: this message and one to a non-related > > thread [Ada95-Compiler Recommendation for Win32]. > > > > - > > > > Sent via Deja.com http://www.deja.com/ > > Before you buy. > > -- > -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ > Technical Director, Distributed IT Solutions (www.averstar.com/tools) > AverStar (formerly Intermetrics, Inc.) Burlington Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Ada 95 based RTOS 2000-02-21 0:00 ` xaplos @ 2000-02-22 0:00 ` Matthew Majka 2000-02-22 0:00 ` xaplos 0 siblings, 1 reply; 42+ messages in thread From: Matthew Majka @ 2000-02-22 0:00 UTC (permalink / raw) xaplos@my-deja.com wrote: > > Thank you very much for the reference to RTEMS. I downloaded version 4 > only to find out that the source files are in C. I keep reading on > several sites that there is a version of RTEMS written in Ada; however, > I can't find it. > > It is my understanding that I can compile Ada source into object files > with GNAT and link them with RTEMS which is written in C to run my > applications on lets say an M68K. Because of the nature of the project > I'm working on - master's thesis - I'd really like to be working with > code from the same language - hence my desire to find the Ada version of > RTEMS. I think I remember hearing that the Ada version of RTEMS is no longer supported/being updated. At one point you could chose from sources in either C or Ada, but apparently the demand for the Ada sources wasn't large enough to justify the effort of producing them. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Ada 95 based RTOS 2000-02-22 0:00 ` Matthew Majka @ 2000-02-22 0:00 ` xaplos 2000-02-22 0:00 ` Ted Dennison ` (3 more replies) 0 siblings, 4 replies; 42+ messages in thread From: xaplos @ 2000-02-22 0:00 UTC (permalink / raw) From what I can gather from the http://www.rtems.army.mil the last version of RTEMS written in Ada was V 3.2.1. I really don't care if it's being updated or maintained since I'm only planning to use it as a reference. If anyone has a copy of this release or a later one, please send it to macrod@earthlink.net - it would help me out considerably. I'm fairly new to the Ada language and have spent a lot of time reading how Ada is superior to C/C++ in design and safety. I'm currious if someone can explain why there are so many RTOS based on C/C++ and "none" (I mean easily and freely available) based on Ada. With Ada's real-time annex and other language features, one would think an Ada-based kernel/run-time would be superior to others. In article <38B2A2A1.FDCDDFE7@honeywell.com>, Matthew Majka <matthew.majka@honeywell.com> wrote: > xaplos@my-deja.com wrote: > > > > Thank you very much for the reference to RTEMS. I downloaded version 4 > > only to find out that the source files are in C. I keep reading on > > several sites that there is a version of RTEMS written in Ada; however, > > I can't find it. > > > > It is my understanding that I can compile Ada source into object files > > with GNAT and link them with RTEMS which is written in C to run my > > applications on lets say an M68K. Because of the nature of the project > > I'm working on - master's thesis - I'd really like to be working with > > code from the same language - hence my desire to find the Ada version of > > RTEMS. > > I think I remember hearing that the Ada version of RTEMS is no longer > supported/being updated. At one point you could chose from sources > in either C or Ada, but apparently the demand for the Ada sources > wasn't large enough to justify the effort of pr Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Ada 95 based RTOS 2000-02-22 0:00 ` xaplos @ 2000-02-22 0:00 ` Ted Dennison 2000-02-22 0:00 ` xaplos 2000-02-22 0:00 ` Marin D. Condic ` (2 subsequent siblings) 3 siblings, 1 reply; 42+ messages in thread From: Ted Dennison @ 2000-02-22 0:00 UTC (permalink / raw) In article <88ugrd$7j7$1@nnrp1.deja.com>, xaplos@my-deja.com wrote: > how Ada is superior to C/C++ in design and safety. I'm currious if > someone can explain why there are so many RTOS based on C/C++ and > "none" (I mean easily and freely available) based on Ada. With Ada's How many RTOS's are there in *any* language that fit your criteria? Two maybe? The fact that you can't easily find freely-available sources for a particular language for either of those two RTOS's can hardly be taken as having some statisticly significant meaning. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Ada 95 based RTOS 2000-02-22 0:00 ` Ted Dennison @ 2000-02-22 0:00 ` xaplos 2000-02-23 0:00 ` Roger Racine 2000-02-25 0:00 ` Mike Silva 0 siblings, 2 replies; 42+ messages in thread From: xaplos @ 2000-02-22 0:00 UTC (permalink / raw) My intentions are not to bad-talk Ada in any way - I'm already convinced its a superior language than C/C++. Your absolutely right in that the specific requirements for any project (especially an RTOS project) rarely can be met with an off-the-shelf product. It's just nice to have some source code available as a reference (especially as a newbie to Ada) when beginning a new project rather than starting from scratch. There are several books available on embedded programming that discuss C/C++ which is really nice for a beginning programming to use as a starting reference. Even though these books probably won't discuss the particulars of your project, it's still a nice reference. I just think having access to Ada sources for low level system programming - like an RTOS - will help beginners like myself become more familiar with the capabilities of Ada. I'm planning on devoting about a 1 to 2 years (probably will be much more but my wife will kill me if I don't get out of school soon) working on an open-source OS written entirely in Ada for wireless devices (similar to the Palm OS, Windows CE, Epoc OS, etc.). I'd like the entire project to be based on Ada from the low-level kernel and memory management all the way to the programming API and GUI. I strongly believe Ada is a perfect language for these types of consumer appliances for obvious reasons. I don't expect to find any RTOS that will meet my all of my requirements for this project; however, having access to the Ada sources for RTEMS would be a great starting point. In article <88umb5$c5p$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > In article <88ugrd$7j7$1@nnrp1.deja.com>, > xaplos@my-deja.com wrote: > > > how Ada is superior to C/C++ in design and safety. I'm currious if > > someone can explain why there are so many RTOS based on C/C++ and > > "none" (I mean easily and freely available) based on Ada. With Ada's > > How many RTOS's are there in *any* language that fit your criteria? Two > maybe? The fact that you can't easily find freely-available sources for > a particular language for either of those two RTOS's can hardly be taken > as having some statisticly significant meaning. > > -- > T.E.D. > > http://www.telepath.com/~dennison/Ted/TED.html > > Sent via Deja.com http://www.deja.co Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Ada 95 based RTOS 2000-02-22 0:00 ` xaplos @ 2000-02-23 0:00 ` Roger Racine 2000-02-24 0:00 ` Simon Wright 2000-02-25 0:00 ` Mike Silva 1 sibling, 1 reply; 42+ messages in thread From: Roger Racine @ 2000-02-23 0:00 UTC (permalink / raw) On Tue, 22 Feb 2000 20:14:11 GMT, xaplos@my-deja.com wrote: >My intentions are not to bad-talk Ada in any way - I'm already convinced >its a superior language than C/C++. Your absolutely right in that the >specific requirements for any project (especially an RTOS project) >rarely can be met with an off-the-shelf product. It's just nice to have >some source code available as a reference (especially as a newbie to >Ada) when beginning a new project rather than starting from scratch. > >There are several books available on embedded programming that discuss >C/C++ which is really nice for a beginning programming to use as a >starting reference. Even though these books probably won't discuss the >particulars of your project, it's still a nice reference. I just think >having access to Ada sources for low level system programming - like an >RTOS - will help beginners like myself become more familiar with the >capabilities of Ada. > >I'm planning on devoting about a 1 to 2 years (probably will be much >more but my wife will kill me if I don't get out of school soon) working >on an open-source OS written entirely in Ada for wireless devices >(similar to the Palm OS, Windows CE, Epoc OS, etc.). I'd like the entire >project to be based on Ada from the low-level kernel and memory >management all the way to the programming API and GUI. I strongly >believe Ada is a perfect language for these types of consumer appliances >for obvious reasons. I don't expect to find any RTOS that will meet my >all of my requirements for this project; however, having access to the >Ada sources for RTEMS would be a great starting point. > A company called TopLayer (www.toplayer.com) has a RTOS based on the GNAT runtime system. Mike Kamrad of that company has given a couple talks at Ada conferences on the subject. I am not sure about the license issues. Their code has "all rights reserved", but it was based on the GNAT source. The GNAT source has pretty open language, but definitely -not- GPL (since it is expected to be used as a library), so the TopLayer code does not appear to be "open by extension". Roger Racine ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Ada 95 based RTOS 2000-02-23 0:00 ` Roger Racine @ 2000-02-24 0:00 ` Simon Wright 2000-02-24 0:00 ` Robert Dewar 0 siblings, 1 reply; 42+ messages in thread From: Simon Wright @ 2000-02-24 0:00 UTC (permalink / raw) rracine@myremarq.com (Roger Racine) writes: > I am not sure about the license issues. Their code has "all rights > reserved", but it was based on the GNAT source. The GNAT source has > pretty open language, but definitely -not- GPL (since it is expected > to be used as a library), so the TopLayer code does not appear to be > "open by extension". "GNAT is free software; you can redistribute it and/or modify it under terms of the GNU General Public License ... "As a special exception, if other files instantiate generics from this unit, or you link this unit with other files to produce an executable, this unit does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU Public License. ... IANAL but seems to me that if I were to base my code on the GNAT sources it would definitely come under the GPL. However, if I just use functionality provided by the GNAT sources, that's a different matter. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Ada 95 based RTOS 2000-02-24 0:00 ` Simon Wright @ 2000-02-24 0:00 ` Robert Dewar 0 siblings, 0 replies; 42+ messages in thread From: Robert Dewar @ 2000-02-24 0:00 UTC (permalink / raw) In article <x7v7lfvt811.fsf@pogner.demon.co.uk>, Simon Wright <simon@pogner.demon.co.uk> wrote: > IANAL but seems to me that if I were to base my code on the > GNAT sources it would definitely come under the GPL. However, > if I just use functionality provided by the GNAT sources, > that's a different matter. That's incorrect. First, if you modify the GNAT sources for your own use, they definitely do not need to be licensed to anyone but yourself, and your modifications can be kept entirely to yourself under whatever restrictions you like. It is only if you decide to distribute the sources that they would be covered by the GPL since otherwise your distribution of the modified sources would violate the original copyright. Second, if you merely write new modules using the same interface as GNAT, then there is definitely no restriction. For instance there is nothing to stop someone providing a proprietary replacement for the GNAT runtime library. As for TopLayer, I think the eventual intention is for them to distribute what they do under the GPL or modified GPL, but they are not yet at that point in their development as I understand the situation. of course you have to check with them to get the definitive story! Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Ada 95 based RTOS 2000-02-22 0:00 ` xaplos 2000-02-23 0:00 ` Roger Racine @ 2000-02-25 0:00 ` Mike Silva 2000-02-26 0:00 ` xaplos 1 sibling, 1 reply; 42+ messages in thread From: Mike Silva @ 2000-02-25 0:00 UTC (permalink / raw) (Tried to post this earlier but seems to have been bit-bucketed...) Do you actually need the RTOS if you're using Ada? Given the concurrency support provided in Ada you may not need it. Of course, the Ada implementation you use will use some RTOS-like code "under the hood" to provide the language concurrency features, but you may be able to do what you want strictly in Ada -- depends on what you're trying to do. I suspect the reason there aren't many (any?) RTOSes in Ada because, unlike C/C++, there's no need for one to do tasking in Ada (yes it's there, but not visible). Mike xaplos@my-deja.com wrote in message <88qli0$gvr$1@nnrp1.deja.com>... >Thank you very much for the reference to RTEMS. I downloaded version 4 >only to find out that the source files are in C. I keep reading on >several sites that there is a version of RTEMS written in Ada; however, >I can't find it. > >It is my understanding that I can compile Ada source into object files >with GNAT and link them with RTEMS which is written in C to run my >applications on lets say an M68K. Because of the nature of the project >I'm working on - master's thesis - I'd really like to be working with >code from the same language - hence my desire to find the Ada version of >RTEMS. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Ada 95 based RTOS 2000-02-25 0:00 ` Mike Silva @ 2000-02-26 0:00 ` xaplos 0 siblings, 0 replies; 42+ messages in thread From: xaplos @ 2000-02-26 0:00 UTC (permalink / raw) I'm an Ada newbie so I'm flying by the seat of my pants:-) I have worked on several large projects in both C/C++ and Java, but have only recently joined the Ada family (thanks to all for sending the RTEMS Ada sources). My goal is to develop an open-source, Ada-based environment for wireless devices - similar to the Palm OS. I'm planning to run it on the M68K processor and imagine the Ada run-time environment must be embedded in the ROM of the device to support the standard Ada packages; that way an application engineer can program third party apps using the standard packages in ROM rather than keeping another copy of the package for each program that references it. I was thinking that rather than trying to support the entire Ada run-time environment, I would use RTEMS or some other Ada-based RTOS to support only the necessary features for this type of OS and minimize overhead. If I'm not making any sense, please correct me (this is the design goal used by the Palm OS - reduce memory by not supporting the standard C run-time library but rather the Palm OS API in ROM). Again, the reasoning behind this type of thinking is from my knowledge of C/C++. In article <UUAt4.1405$dw3.82979@news.wenet.net>, "Mike Silva" <mjsilva@jps.net> wrote: > (Tried to post this earlier but seems to have been bit-bucketed...) > > Do you actually need the RTOS if you're using Ada? Given the concurrency > support provided in Ada you may not need it. Of course, the Ada > implementation you use will use some RTOS-like code "under the hood" to > provide the language concurrency features, but you may be able to do what > you want strictly in Ada -- depends on what you're trying to do. > > I suspect the reason there aren't many (any?) RTOSes in Ada because, unlike > C/C++, there's no need for one to do tasking in Ada (yes it's there, but not > visible). > > Mike > > xaplos@my-deja.com wrote in message <88qli0$gvr$1@nnrp1.deja.com>... > >Thank you very much for the reference to RTEMS. I downloaded version 4 > >only to find out that the source files are in C. I keep reading on > >several sites that there is a version of RTEMS written in Ada; however, > >I can't find it. > > > >It is my understanding that I can compile Ada source into object files > >with GNAT and link them with RTEMS which is written in C to run my > >applications on lets say an M68K. Because of the nature of the project > >I'm working on - master's thesis - I'd really like to be working with > >code from the same language - hence my desire to find the Ada ver Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Ada 95 based RTOS 2000-02-22 0:00 ` xaplos 2000-02-22 0:00 ` Ted Dennison @ 2000-02-22 0:00 ` Marin D. Condic 2000-02-22 0:00 ` Stanley R. Allen 2000-02-23 0:00 ` Tarjei T. Jensen 3 siblings, 0 replies; 42+ messages in thread From: Marin D. Condic @ 2000-02-22 0:00 UTC (permalink / raw) xaplos@my-deja.com wrote: > I'm fairly new to the Ada language and have spent a lot of time reading > how Ada is superior to C/C++ in design and safety. I'm currious if > someone can explain why there are so many RTOS based on C/C++ and "none" > (I mean easily and freely available) based on Ada. With Ada's real-time > annex and other language features, one would think an Ada-based > kernel/run-time would be superior to others. In many realtime and embedded applications, the tradition has been for the Ada compiler to provide a runtime kernel which implements the tasking primitives and similar features needed to make the code run on a bare machine. This is a little different than the tradition with C/C++ compilers that rode on top of Unix (and others) and someone else would provide a plug-compatible kernel as a separate piece. Many Ada compilers have been targeted to unique hardware or somewhat obscure processors so an RTOS would have been hard to develop that fit all those niches. Hence reliance on a compiler provided RTK. You may discover that there are Ada compilers out there which target your favorite C/C++ based RTOS. An RTOS is, after all, nothing more than another operating system. Just as you can target many languages to Unix, you can target Ada to run on top of any RTOS. Check with some of the compiler vendors. There are links to many of them on my web page. MDC -- ============================================================= Marin David Condic - Quadrus Corporation - 1.800.555.3393 1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233 http://www.quadruscorp.com/ m c o n d i c @ q u a d r u s c o r p . c o m ***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS*** Visit my web site at: http://www.mcondic.com/ "Because that's where they keep the money." -- Willie Sutton when asked why he robbed banks. ============================================================= ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Ada 95 based RTOS 2000-02-22 0:00 ` xaplos 2000-02-22 0:00 ` Ted Dennison 2000-02-22 0:00 ` Marin D. Condic @ 2000-02-22 0:00 ` Stanley R. Allen 2000-02-23 0:00 ` Tarjei T. Jensen 3 siblings, 0 replies; 42+ messages in thread From: Stanley R. Allen @ 2000-02-22 0:00 UTC (permalink / raw) xaplos@my-deja.com wrote: > > I'm fairly new to the Ada language and have spent a lot of time reading > how Ada is superior to C/C++ in design and safety. I'm currious if > someone can explain why there are so many RTOS based on C/C++ and "none" > (I mean easily and freely available) based on Ada. With Ada's real-time > annex and other language features, one would think an Ada-based > kernel/run-time would be superior to others. How about: "Against stupidity the gods themselves contend in vain" -- Schiller ? -- Stanley Allen mailto:Stanley_R_Allen@raytheon.com ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Ada 95 based RTOS 2000-02-22 0:00 ` xaplos ` (2 preceding siblings ...) 2000-02-22 0:00 ` Stanley R. Allen @ 2000-02-23 0:00 ` Tarjei T. Jensen 2000-02-23 0:00 ` Gautier 2000-02-23 0:00 ` Ada 95 based RTOS Ted Dennison 3 siblings, 2 replies; 42+ messages in thread From: Tarjei T. Jensen @ 2000-02-23 0:00 UTC (permalink / raw) xaplos@my-deja.com wrote >I'm fairly new to the Ada language and have spent a lot of time reading >how Ada is superior to C/C++ in design and safety. I'm currious if >someone can explain why there are so many RTOS based on C/C++ and "none" >(I mean easily and freely available) based on Ada. With Ada's real-time >annex and other language features, one would think an Ada-based >kernel/run-time would be superior to others. If your read (and believe) what the Jargon file (http://www.tuxedo.org/~esr/jargon/) writes about Ada then it is not surprising that languages like Ada are not popular with the hackers. Ada has had a terrible reputation. To me the Ada vendors seems to have been very lethargic - perhaps unable to to long term planning. Why should they, Uncle Sam seems to have been very generous to many. It is with GNAT that we have the means to show how great a language Ada is. The availability of GNAT gives the Ada community a low cost Ada compiler which can be the basis for long term work (10+ years) to increase Ada usage. The increased use of Ada in education seems to have given good results and there is a steady increase in projects that is done in Ada. The Adapower site should be a good indication of this. If this trend continues it is not unthinkable that Ada reaches the mainstream within the next 5 years. With an expanding user base in eduation it is probably a matter of time before we get an application which will force people to want to learn Ada (like Zope has done for Python). Greetings, ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Ada 95 based RTOS 2000-02-23 0:00 ` Tarjei T. Jensen @ 2000-02-23 0:00 ` Gautier 2000-02-23 0:00 ` Ehud Lamm 2000-02-23 0:00 ` Ada 95 based RTOS Ted Dennison 1 sibling, 1 reply; 42+ messages in thread From: Gautier @ 2000-02-23 0:00 UTC (permalink / raw) > If your read (and believe) what the Jargon file > (http://www.tuxedo.org/~esr/jargon/) writes about Ada then it is not surprising > that languages like Ada are not popular with the hackers. Ada has had a > terrible reputation. An interesting thing is that these impressions seem to be just based on gossips (Ada 83, with the first compiler attempts) or simply copied from the criticism about Pascal - which is somehow justified for Pascal. A fundamental reason why fundamental things do not change in software as fast as for other technical domains is that an ASCII text even doesn't become yellow with the time. The "Ada" topic in the Jargon file must be about 20 years old, but a newcomer could take it as fresh information... Anyway the whole text smells its 1970-early 1980, with plenty of PDP-11 and so on... Maybe for the "Elderly Hackers Club" ?... -- Gautier _____\\________________\_______\_________ http://members.xoom.com/gdemont/gsoft.htm ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Ada 95 based RTOS 2000-02-23 0:00 ` Gautier @ 2000-02-23 0:00 ` Ehud Lamm 2000-02-23 0:00 ` Why should hackers love Ada. (Re: Ada 95 based RTOS) Marin D. Condic 0 siblings, 1 reply; 42+ messages in thread From: Ehud Lamm @ 2000-02-23 0:00 UTC (permalink / raw) Hi I have a rough outline for a memo titled "Why should hackers love Ada." Beacuse of lack of time, it is yet to be finished. If someone wants to cooperate - let me konw Ehud Lamm mslamm@mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm <== My home on the web Check it out and subscribe to the E-List- for interesting essays and more! On Wed, 23 Feb 2000, Gautier wrote: |> If your read (and believe) what the Jargon file |> (http://www.tuxedo.org/~esr/jargon/) writes about Ada then it is not surprising |> that languages like Ada are not popular with the hackers. Ada has had a |> terrible reputation. | |An interesting thingis that these impressions seem to be just based on gossips |(Ada 83, with the first compiler attempts) or simply copied from the criticism |about Pascal - which is somehow justified for Pascal. |A fundamental reason why fundamental things do not change in software as fast as |for other technical domains is that an ASCII text even doesn't become yellow with |the time. The "Ada" topic in the Jargon file must be about 20 years old, but a |newcomer could take it as fresh information... Anyway the whole text smells |its 1970-early 1980, with plenty of PDP-11 and so on... Maybe for the "Elderly |Hackers Club" ?... | |-- |Gautier | |_____\\________________\_______\_________ |http://members.xoom.com/gdemont/gsoft.htm | | ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-23 0:00 ` Ehud Lamm @ 2000-02-23 0:00 ` Marin D. Condic 2000-02-23 0:00 ` Gary ` (2 more replies) 0 siblings, 3 replies; 42+ messages in thread From: Marin D. Condic @ 2000-02-23 0:00 UTC (permalink / raw) Ehud Lamm wrote: > > Hi > > I have a rough outline for a memo titled "Why should hackers love Ada." > Beacuse of lack of time, it is yet to be finished. If someone wants to > cooperate - let me konw > In some ways, you'd think "hackers" should be fascinated with Ada. It provides all sorts of facilities to do bit-twiddling and low level access to the hardware. Tasks seem to provide ample opportunity for playing with sophisticated OS or OS-like features. The control of the representation of data down to bits, endianness, etc. ought to appeal to people who like to get control of the bare machine. But I suppose those who would hang the moniker "hacker" upon themselves really want assembly language - only without the inconvenience of having to learn a new one every time new hardware comes out. Hence the popularity of things like C with hackers. MDC -- ============================================================= Marin David Condic - Quadrus Corporation - 1.800.555.3393 1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233 http://www.quadruscorp.com/ m c o n d i c @ q u a d r u s c o r p . c o m ***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS*** Visit my web site at: http://www.mcondic.com/ "Because that's where they keep the money." -- Willie Sutton when asked why he robbed banks. ============================================================= ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-23 0:00 ` Why should hackers love Ada. (Re: Ada 95 based RTOS) Marin D. Condic @ 2000-02-23 0:00 ` Gary 2000-02-24 0:00 ` Gisle S�lensminde 2000-02-24 0:00 ` Marin D. Condic 2000-02-23 0:00 ` Vladimir Olensky 2000-02-24 0:00 ` Ehud Lamm 2 siblings, 2 replies; 42+ messages in thread From: Gary @ 2000-02-23 0:00 UTC (permalink / raw) Hi, "Marin D. Condic" wrote: > Ehud Lamm wrote: > > > In some ways, you'd think "hackers" should be fascinated with Ada. It > provides all sorts of facilities to do bit-twiddling and low level > access to the hardware. I see this reference to ADA being good at bit twiddling, periodically. Virtually all high-level languages provide facilities for bit twiddling. Is there something unique about ADA (I'm a non-ADA programmers, sorry). Is this a reference to a transfer function (other languages have this) or memory aliasing tricks? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-23 0:00 ` Gary @ 2000-02-24 0:00 ` Gisle S�lensminde 2000-02-24 0:00 ` Marin D. Condic 1 sibling, 0 replies; 42+ messages in thread From: Gisle S�lensminde @ 2000-02-24 0:00 UTC (permalink / raw) In article <38B47521.1A80B6A1@lmtas.lmco.com>, Gary wrote: >Hi, > >"Marin D. Condic" wrote: > >> Ehud Lamm wrote: >> > >> In some ways, you'd think "hackers" should be fascinated with Ada. It >> provides all sorts of facilities to do bit-twiddling and low level >> access to the hardware. > >I see this reference to ADA being good at bit twiddling, periodically. >Virtually all high-level languages provide facilities for bit twiddling. Is >there something unique about ADA (I'm a non-ADA programmers, sorry). Is this >a reference to a transfer function (other languages have this) or memory >aliasing tricks? > Because Ada heve some good methods for lowlevel access to hardware, and this includes bit twidling. Some bit operations are: - Bitwise logical operators for modular types, and in the package interfaces there is operators for bitwise shift and rotatate. - Packed arrays of boolean(and other types). Yoy can declare an array of booleans, where each element corresponds to one bit. A 32-bit array of packed booleans fits in one word on a 32-bit computer. - The compiler knows whether the target is a big endian or a little endian architecture, and you have tests to find it out, which can be used in code to make it portible. - Representation clauses in records, so you can control where "the bits goes" in a record. -- Gisle S�lensminde ( gisle@ii.uib.no ) ln -s /dev/null ~/.netscape/cookies ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-23 0:00 ` Gary 2000-02-24 0:00 ` Gisle S�lensminde @ 2000-02-24 0:00 ` Marin D. Condic 2000-02-24 0:00 ` Larry Kilgallen 1 sibling, 1 reply; 42+ messages in thread From: Marin D. Condic @ 2000-02-24 0:00 UTC (permalink / raw) Gary wrote: > I see this reference to ADA being good at bit twiddling, periodically. > Virtually all high-level languages provide facilities for bit twiddling. Is > there something unique about ADA (I'm a non-ADA programmers, sorry). Is this > a reference to a transfer function (other languages have this) or memory > aliasing tricks? Well, I don't know what the rest of the world means by "bit twiddling" but I know what *I* mean when I say that. ;-) You have all the facilities you need in Ada (Ada95 - Ada83 didn't do this well) to do shifting, masking & other manipulations of individual bits within words. If you've ever had to do interfacing to low level devices, hardware registers, I/O ports, etc., then you know that you can't always deal with data as an "abstraction" where you can allow the compiler to pick whatever representations it wants and manipulate things any way it likes. Often I have been up against time constraints where even if a high level method of solving the problem may work fine, we dipped into bit masks and logical operators because they degenerated to much more efficient code. Ada95 lets you get at things like this when you need to. The difference between Ada and C on this issue is that with Ada it is a "last resort" whereas with C it is a "way of life". (Look at how lots of bindings to C stuff includes numeric constants for specifying options by or'ing together the constants. While Ada can do that, it isn't the usual idiom.) MDC -- ============================================================= Marin David Condic - Quadrus Corporation - 1.800.555.3393 1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233 http://www.quadruscorp.com/ m c o n d i c @ q u a d r u s c o r p . c o m ***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS*** Visit my web site at: http://www.mcondic.com/ "Because that's where they keep the money." -- Willie Sutton when asked why he robbed banks. ============================================================= ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-24 0:00 ` Marin D. Condic @ 2000-02-24 0:00 ` Larry Kilgallen 2000-02-25 0:00 ` Gary Scott 2000-02-26 0:00 ` Robert Dewar 0 siblings, 2 replies; 42+ messages in thread From: Larry Kilgallen @ 2000-02-24 0:00 UTC (permalink / raw) In article <38B55928.8A0EAB06@quadruscorp.com>, "Marin D. Condic" <mcondic-nospam@quadruscorp.com> writes: > Gary wrote: >> I see this reference to ADA being good at bit twiddling, periodically. >> Virtually all high-level languages provide facilities for bit twiddling. Is >> there something unique about ADA (I'm a non-ADA programmers, sorry). Is this >> a reference to a transfer function (other languages have this) or memory >> aliasing tricks? > > Well, I don't know what the rest of the world means by "bit twiddling" > but I know what *I* mean when I say that. ;-) > > You have all the facilities you need in Ada (Ada95 - Ada83 didn't do > this well) to do shifting, masking & other manipulations of individual > bits within words. If you've ever had to do interfacing to low level > devices, hardware registers, I/O ports, etc., then you know that you > can't always deal with data as an "abstraction" where you can allow the > compiler to pick whatever representations it wants and manipulate things > any way it likes. Often I have been up against time constraints where > even if a high level method of solving the problem may work fine, we > dipped into bit masks and logical operators because they degenerated to > much more efficient code. > > Ada95 lets you get at things like this when you need to. The difference > between Ada and C on this issue is that with Ada it is a "last resort" > whereas with C it is a "way of life". (Look at how lots of bindings to C > stuff includes numeric constants for specifying options by or'ing > together the constants. While Ada can do that, it isn't the usual > idiom.) I think a major advantage of Ada is that it lets the programmer deal at a higher level for the main body of the program, while only the interface description contains the specification that bits 2-4 are treated as a numeric field for the unit number. The compiler aids and enforces adherence to that specification without requiring the programmer to be constantly thinking about it and getting it right. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-24 0:00 ` Larry Kilgallen @ 2000-02-25 0:00 ` Gary Scott 2000-02-25 0:00 ` Marin D. Condic 2000-02-25 0:00 ` Mike Silva 2000-02-26 0:00 ` Robert Dewar 1 sibling, 2 replies; 42+ messages in thread From: Gary Scott @ 2000-02-25 0:00 UTC (permalink / raw) Larry Kilgallen wrote: > In article <38B55928.8A0EAB06@quadruscorp.com>, "Marin D. Condic" <mcondic-nospam@quadruscorp.com> writes: > > Gary wrote: > >> I see this reference to ADA being good at bit twiddling, periodically. > >> Virtually all high-level languages provide facilities for bit twiddling. Is > >> there something unique about ADA (I'm a non-ADA programmers, sorry). Is this > >> a reference to a transfer function (other languages have this) or memory > >> aliasing tricks? > > > > Well, I don't know what the rest of the world means by "bit twiddling" > > but I know what *I* mean when I say that. ;-) > > > > You have all the facilities you need in Ada (Ada95 - Ada83 didn't do > > this well) to do shifting, masking & other manipulations of individual > > bits within words. If you've ever had to do interfacing to low level > > devices, hardware registers, I/O ports, etc., then you know that you > > can't always deal with data as an "abstraction" where you can allow the > > compiler to pick whatever representations it wants and manipulate things > > any way it likes. Often I have been up against time constraints where > > even if a high level method of solving the problem may work fine, we > > dipped into bit masks and logical operators because they degenerated to > > much more efficient code. > > > > Ada95 lets you get at things like this when you need to. The difference > > between Ada and C on this issue is that with Ada it is a "last resort" > > whereas with C it is a "way of life". (Look at how lots of bindings to C > > stuff includes numeric constants for specifying options by or'ing > > together the constants. While Ada can do that, it isn't the usual > > idiom.) > > I think a major advantage of Ada is that it lets the programmer deal > at a higher level for the main body of the program, while only the > interface description contains the specification that bits 2-4 are > treated as a numeric field for the unit number. The compiler aids > and enforces adherence to that specification without requiring the > programmer to be constantly thinking about it and getting it right. This is a good feature, but many other languages have similar features (some very old like Jovial and PL/1). In other languages, my experience is that you simply define pack/unpack/scale routines and write the main executive and high-level functionality in a high-level fashion (possibly OO) and simply invoke these low-level "reformat" routines at the top and bottom of the frame (or as-required). Then again, I'm also used to being able to embed assembly to gain access to an interval timer or generate an interrupt right into the high-level language code. -- Gary Scott mailto:scottg@flash.net mailto:webmaster@fortranlib.com http://www.fortranlib.com ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-25 0:00 ` Gary Scott @ 2000-02-25 0:00 ` Marin D. Condic 2000-02-25 0:00 ` Gary 2000-02-25 0:00 ` Mike Silva 1 sibling, 1 reply; 42+ messages in thread From: Marin D. Condic @ 2000-02-25 0:00 UTC (permalink / raw) Gary Scott wrote: > This is a good feature, but many other languages have similar features (some very old like Jovial and PL/1). > In other languages, my experience is that you simply define pack/unpack/scale routines and write the main > executive and high-level functionality in a high-level fashion (possibly OO) and simply invoke these low-level > "reformat" routines at the top and bottom of the frame (or as-required). Then again, I'm also used to being > able to embed assembly to gain access to an interval timer or generate an interrupt right into the high-level > language code. > There are lots of languages that give you good control of the underlying representation of data and access to the hardware. Jovial was better than most in this respect. However, I think there is a difference between Ada and other languages in this respect. Ada tends towards encouraging encapsulation of the low-level features so that they exist in an isolated spot, whereas other languages treat access to low level features as the "normal" mode of writing code. For example, you mention embedded assembly. Ada will let you do that but you have to isolate it in a subprogram - you can't just stick assembler instructions anywhere you feel like. MDC -- ============================================================= Marin David Condic - Quadrus Corporation - 1.800.555.3393 1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233 http://www.quadruscorp.com/ m c o n d i c @ q u a d r u s c o r p . c o m ***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS*** Visit my web site at: http://www.mcondic.com/ "Because that's where they keep the money." -- Willie Sutton when asked why he robbed banks. ============================================================= ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-25 0:00 ` Marin D. Condic @ 2000-02-25 0:00 ` Gary 0 siblings, 0 replies; 42+ messages in thread From: Gary @ 2000-02-25 0:00 UTC (permalink / raw) "Marin D. Condic" wrote: > Gary Scott wrote: > > This is a good feature, but many other languages have similar features (some very old like Jovial and PL/1). > > In other languages, my experience is that you simply define pack/unpack/scale routines and write the main > > executive and high-level functionality in a high-level fashion (possibly OO) and simply invoke these low-level > > "reformat" routines at the top and bottom of the frame (or as-required). Then again, I'm also used to being > > able to embed assembly to gain access to an interval timer or generate an interrupt right into the high-level > > language code. > > > There are lots of languages that give you good control of the underlying > representation of data and access to the hardware. Jovial was better > than most in this respect. However, I think there is a difference > between Ada and other languages in this respect. Ada tends towards > encouraging encapsulation of the low-level features so that they exist > in an isolated spot, whereas other languages treat access to low level > features as the "normal" mode of writing code. For example, you mention > embedded assembly. Ada will let you do that but you have to isolate it > in a subprogram - you can't just stick assembler instructions anywhere > you feel like. > This has quite a lot to do with programming style. I can encapsulate/isolate "low-level" functions in almost any language, but few languages restrict my choices. I agree that encapsulation/isolation is a good thing in general and I practice it for the most part, regardless of the language that I use (primarily for portability reasons). I prefer to have the freedom to make those types of decisions. For some applications, it may be entirely appropriate to generate an interrupt in a program main. > > MDC > -- > ============================================================= > Marin David Condic - Quadrus Corporation - 1.800.555.3393 > 1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233 > http://www.quadruscorp.com/ > m c o n d i c @ q u a d r u s c o r p . c o m > > ***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS*** > > Visit my web site at: http://www.mcondic.com/ > > "Because that's where they keep the money." > -- Willie Sutton when asked why he robbed banks. > ============================================================= ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-25 0:00 ` Gary Scott 2000-02-25 0:00 ` Marin D. Condic @ 2000-02-25 0:00 ` Mike Silva 2000-02-26 0:00 ` Gary Scott 1 sibling, 1 reply; 42+ messages in thread From: Mike Silva @ 2000-02-25 0:00 UTC (permalink / raw) Gary Scott wrote in message <38B5C9E6.143A32D6@flash.net>... >Larry Kilgallen wrote: > >> In article <38B55928.8A0EAB06@quadruscorp.com>, "Marin D. Condic" <mcondic-nospam@quadruscorp.com> writes: >> > Gary wrote: >> >> I see this reference to ADA being good at bit twiddling, periodically. >> >> Virtually all high-level languages provide facilities for bit twiddling. Is >> >> there something unique about ADA (I'm a non-ADA programmers, sorry). Is this >> >> a reference to a transfer function (other languages have this) or memory >> >> aliasing tricks? >> > >> > Well, I don't know what the rest of the world means by "bit twiddling" >> > but I know what *I* mean when I say that. ;-) >> > >> > You have all the facilities you need in Ada (Ada95 - Ada83 didn't do >> > this well) to do shifting, masking & other manipulations of individual >> > bits within words. If you've ever had to do interfacing to low level >> > devices, hardware registers, I/O ports, etc., then you know that you >> > can't always deal with data as an "abstraction" where you can allow the >> > compiler to pick whatever representations it wants and manipulate things >> > any way it likes. Often I have been up against time constraints where >> > even if a high level method of solving the problem may work fine, we >> > dipped into bit masks and logical operators because they degenerated to >> > much more efficient code. >> > >> > Ada95 lets you get at things like this when you need to. The difference >> > between Ada and C on this issue is that with Ada it is a "last resort" >> > whereas with C it is a "way of life". (Look at how lots of bindings to C >> > stuff includes numeric constants for specifying options by or'ing >> > together the constants. While Ada can do that, it isn't the usual >> > idiom.) >> >> I think a major advantage of Ada is that it lets the programmer deal >> at a higher level for the main body of the program, while only the >> interface description contains the specification that bits 2-4 are >> treated as a numeric field for the unit number. The compiler aids >> and enforces adherence to that specification without requiring the >> programmer to be constantly thinking about it and getting it right. > >This is a good feature, but many other languages have similar features (some very old like Jovial and PL/1). >In other languages, my experience is that you simply define pack/unpack/scale routines and write the main >executive and high-level functionality in a high-level fashion (possibly OO) and simply invoke these low-level >"reformat" routines at the top and bottom of the frame (or as-required). Then again, I'm also used to being >able to embed assembly to gain access to an interval timer or generate an interrupt right into the high-level >language code. It seems that you are challenging the group to prove that Ada is somehow "the best" at "bit-twiddling". I suspect that the only claim that can be made is that Ada has very good support for such things -- not only bit-twiddling but also e.g. specification of data representations, tasking and interrupt handling. Ada is simply a very nice general purpose language that has everything you need for cuddling up to the hardware. Mike ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-25 0:00 ` Mike Silva @ 2000-02-26 0:00 ` Gary Scott 0 siblings, 0 replies; 42+ messages in thread From: Gary Scott @ 2000-02-26 0:00 UTC (permalink / raw) Mike Silva wrote: > Gary Scott wrote in message <38B5C9E6.143A32D6@flash.net>... > >Larry Kilgallen wrote: > > > >> In article <38B55928.8A0EAB06@quadruscorp.com>, "Marin D. Condic" > <mcondic-nospam@quadruscorp.com> writes: > >> > Gary wrote: > >> >> I see this reference to ADA being good at bit twiddling, periodically. > >> >> Virtually all high-level languages provide facilities for bit > twiddling. Is > >> >> there something unique about ADA (I'm a non-ADA programmers, sorry). > Is this > >> >> a reference to a transfer function (other languages have this) or > memory > >> >> aliasing tricks? > >> > > >> > Well, I don't know what the rest of the world means by "bit twiddling" > >> > but I know what *I* mean when I say that. ;-) > >> > > >> > You have all the facilities you need in Ada (Ada95 - Ada83 didn't do > >> > this well) to do shifting, masking & other manipulations of individual > >> > bits within words. If you've ever had to do interfacing to low level > >> > devices, hardware registers, I/O ports, etc., then you know that you > >> > can't always deal with data as an "abstraction" where you can allow the > >> > compiler to pick whatever representations it wants and manipulate > things > >> > any way it likes. Often I have been up against time constraints where > >> > even if a high level method of solving the problem may work fine, we > >> > dipped into bit masks and logical operators because they degenerated to > >> > much more efficient code. > >> > > >> > Ada95 lets you get at things like this when you need to. The difference > >> > between Ada and C on this issue is that with Ada it is a "last resort" > >> > whereas with C it is a "way of life". (Look at how lots of bindings to > C > >> > stuff includes numeric constants for specifying options by or'ing > >> > together the constants. While Ada can do that, it isn't the usual > >> > idiom.) > >> > >> I think a major advantage of Ada is that it lets the programmer deal > >> at a higher level for the main body of the program, while only the > >> interface description contains the specification that bits 2-4 are > >> treated as a numeric field for the unit number. The compiler aids > >> and enforces adherence to that specification without requiring the > >> programmer to be constantly thinking about it and getting it right. > > > >This is a good feature, but many other languages have similar features > (some very old like Jovial and PL/1). > >In other languages, my experience is that you simply define > pack/unpack/scale routines and write the main > >executive and high-level functionality in a high-level fashion (possibly > OO) and simply invoke these low-level > >"reformat" routines at the top and bottom of the frame (or as-required). > Then again, I'm also used to being > >able to embed assembly to gain access to an interval timer or generate an > interrupt right into the high-level > >language code. > > It seems that you are challenging the group to prove that Ada is somehow > "the best" at "bit-twiddling". I suspect that the only claim that can be > made is that Ada has very good support for such things -- not only > bit-twiddling but also e.g. specification of data representations, tasking > and interrupt handling. Ada is simply a very nice general purpose language > that has everything you need for cuddling up to the hardware. :-) I wasn't really challenging the group to prove Ada's worth, I'm just an interested non-ADA programmer. My company uses Ada 83 extensively and has had significant difficulty meeting memory footprint and code execution performance criteria. I believe this to be mostly the result of poor management decisions regarding forced use of OO in inappropriate ways (yes I know its Ada 83, not Ada 95). I'm really just interested in understanding better the reasons for these difficulties. > > > Mike -- Gary Scott mailto:scottg@flash.net mailto:webmaster@fortranlib.com http://www.fortranlib.com ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-24 0:00 ` Larry Kilgallen 2000-02-25 0:00 ` Gary Scott @ 2000-02-26 0:00 ` Robert Dewar 2000-02-26 0:00 ` Gary Scott 1 sibling, 1 reply; 42+ messages in thread From: Robert Dewar @ 2000-02-26 0:00 UTC (permalink / raw) > > Gary wrote: > >> I see this reference to ADA being good at bit twiddling, periodically. > >> Virtually all high-level languages provide facilities for bit twiddling. Sure, but the facilities in Ada are far more powerful, allow more control, and most importantly, provide a much better level of abstraction. For example, packed bit arrays are a powerful feature missing from C. Sure you can program this yourself in C, but it is messy, error prone, and results in ugly and possibly inefficient code. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-26 0:00 ` Robert Dewar @ 2000-02-26 0:00 ` Gary Scott 2000-03-07 0:00 ` Mike Dimmick 0 siblings, 1 reply; 42+ messages in thread From: Gary Scott @ 2000-02-26 0:00 UTC (permalink / raw) Robert Dewar wrote: > > > Gary wrote: > > >> I see this reference to ADA being good at bit twiddling, > periodically. > > >> Virtually all high-level languages provide facilities for > bit twiddling. > > Sure, but the facilities in Ada are far more powerful, allow > more control, and most importantly, provide a much better level > of abstraction. For example, packed bit arrays are a powerful > feature missing from C. Sure you can program this yourself in > C, but it is messy, error prone, and results in ugly and > possibly inefficient code. > C or C++ or both? Fortran 95 has better facilities than C (and certainly better syntax)...I do wish, however, that support for packed bit arrays was more widespread. > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- Gary Scott mailto:scottg@flash.net mailto:webmaster@fortranlib.com http://www.fortranlib.com ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-26 0:00 ` Gary Scott @ 2000-03-07 0:00 ` Mike Dimmick 2000-03-10 0:00 ` Wil 0 siblings, 1 reply; 42+ messages in thread From: Mike Dimmick @ 2000-03-07 0:00 UTC (permalink / raw) "Gary Scott" <scottg@flash.net> wrote in message news:38B80EBA.721830@flash.net... > Robert Dewar wrote: > > > > > Gary wrote: > > > >> I see this reference to ADA being good at bit twiddling, > > periodically. > > > >> Virtually all high-level languages provide facilities for > > bit twiddling. > > > > Sure, but the facilities in Ada are far more powerful, allow > > more control, and most importantly, provide a much better level > > of abstraction. For example, packed bit arrays are a powerful > > feature missing from C. Sure you can program this yourself in > > C, but it is messy, error prone, and results in ugly and > > possibly inefficient code. > > > > C or C++ or both? Fortran 95 has better facilities than C (and certainly better > syntax)...I do wish, however, that support for packed bit arrays was more > widespread. C. C++ has the <bitvector> as part of the standard library (alright, it's not part of the language, but it should be there on all implementations of standard C++). Unfortunately not all compilers are standards-compliant yet. MSVC 6 is close, but missing a few things; GCC (egcs) isn't quite there yet either. For example, egcs has only just added support for namespaces, while some of the stream_iterators are broken on MS VC++. As an example of this, try compiling some of Stroustrup's examples from 'The C++ Programming Language'. I'd advise anyone considering flaming C++ to look at this book to see what it's truly capable of, and how you should now program in C++ given the standard language and its library.[1] The C++ standards committee stole quite a few ideas from Ada95. -- Mike Dimmick [1] The first rule is, forget anything and everything you ever knew about C. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-03-07 0:00 ` Mike Dimmick @ 2000-03-10 0:00 ` Wil 2000-03-10 0:00 ` Ada OS again " David Starner 2000-03-11 0:00 ` David Botton 0 siblings, 2 replies; 42+ messages in thread From: Wil @ 2000-03-10 0:00 UTC (permalink / raw) On Tue, 7 Mar 2000 20:37:37 -0000, "Mike Dimmick" <mike@dimmick.demon.co.uk> wrote: Thank God Stroustrup never borrowed tasks from Ada. Otherwise the standard never gets done. On the other hand, C++ could go for another 10 years without a standard, and yet, enjoy a popularity than (standardized) Ada can only dream about. >As an example of this, try compiling some of Stroustrup's examples from >'The C++ Programming Language'. I'd advise anyone considering flaming >C++ to look at this book to see what it's truly capable of, and how you >should now program in C++ given the standard language and its >library.[1] The C++ standards committee stole quite a few ideas from >Ada95. > >-- >Mike Dimmick I can't. I am typing this from an OS written in C ! Will that Ada OS ever get done, or is it just a hoax? >[1] The first rule is, forget anything and everything you ever knew >about C. > Will ^ permalink raw reply [flat|nested] 42+ messages in thread
* Ada OS again Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-03-10 0:00 ` Wil @ 2000-03-10 0:00 ` David Starner 2000-03-11 0:00 ` David Botton 1 sibling, 0 replies; 42+ messages in thread From: David Starner @ 2000-03-10 0:00 UTC (permalink / raw) On Fri, 10 Mar 2000 01:52:42 GMT, Wil <wv@fiam.net> wrote: >I can't. I am typing this from an OS written in C ! Will that Ada OS >ever get done, or is it just a hoax? How long do you think it takes to write an OS? Especially when you're designing it from scratch, and try and blaze a new path. (Personally, I think it's never going to work if they continue to be as iconoclastic as they are, but it's far to early to say.) -- David Starner - dstarner98@aasaa.ofe.org Only a nerd would worry about wrong parentheses with square brackets. But that's what mathematicians are. -- Dr. Burchard, math professor at OSU ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-03-10 0:00 ` Wil 2000-03-10 0:00 ` Ada OS again " David Starner @ 2000-03-11 0:00 ` David Botton 1 sibling, 0 replies; 42+ messages in thread From: David Botton @ 2000-03-11 0:00 UTC (permalink / raw) You may want to join the new mail list for AdaOS and see how things are going. Send the word subscribe in the body to AdaOS-list-request@adapower.com David Botton Wil wrote in message <38c85476.1996324@news.fiam.net>... >Will that Ada OS >ever get done, or is it just a hoax? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-23 0:00 ` Why should hackers love Ada. (Re: Ada 95 based RTOS) Marin D. Condic 2000-02-23 0:00 ` Gary @ 2000-02-23 0:00 ` Vladimir Olensky 2000-02-23 0:00 ` Gautier 2000-02-24 0:00 ` David C. Hoos, Sr. 2000-02-24 0:00 ` Ehud Lamm 2 siblings, 2 replies; 42+ messages in thread From: Vladimir Olensky @ 2000-02-23 0:00 UTC (permalink / raw) Marin D. Condic wrote in message <38B41432.88D7389F@quadruscorp.com>... >But I suppose those who would hang the moniker "hacker" upon themselves >really want assembly language - only without the inconvenience of having >to learn a new one every time new hardware comes out. Hence the >popularity of things like C with hackers. > There even exists HLA (High Level Assembler) project which is nothing more than new variation of C. Intention is to use it instead of different assemblers. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-23 0:00 ` Vladimir Olensky @ 2000-02-23 0:00 ` Gautier 2000-02-24 0:00 ` Ehud Lamm 2000-02-24 0:00 ` David C. Hoos, Sr. 1 sibling, 1 reply; 42+ messages in thread From: Gautier @ 2000-02-23 0:00 UTC (permalink / raw) > There even exists HLA (High Level Assembler) project which is nothing > more than new variation of C. > Intention is to use it instead of different assemblers. There is also C-- http://www.research.microsoft.com/~simonpj/c--.html (IMHO: whatever ++,--,... it is always a macro-assembler...) BTW: Ada is also good for hacking. The "'range" & so attributes allow to write faster your code, with less thinking, and obtain almost immediately working code-cracking applets. In addition: understandable after 6 months, even with poor formatting! -- Gautier _____\\________________\_______\ http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-23 0:00 ` Gautier @ 2000-02-24 0:00 ` Ehud Lamm 0 siblings, 0 replies; 42+ messages in thread From: Ehud Lamm @ 2000-02-24 0:00 UTC (permalink / raw) On Wed, 23 Feb 2000, Gautier wrote: | In addition: understandable after 6 months, |even with poor formatting! | But this takes all the fun from reading the source! Now every wannabe will be able to read the source. Ehud Lamm mslamm@mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm <== My home on the web Check it out and subscribe to the E-List- for interesting essays and more! ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-23 0:00 ` Vladimir Olensky 2000-02-23 0:00 ` Gautier @ 2000-02-24 0:00 ` David C. Hoos, Sr. 2000-02-24 0:00 ` Vladimir Olensky 1 sibling, 1 reply; 42+ messages in thread From: David C. Hoos, Sr. @ 2000-02-24 0:00 UTC (permalink / raw) Vladimir Olensky <vladimir_olensky@yahoo.com> wrote in message news:sb8gj38sr2a132@corp.supernews.com... > > Marin D. Condic wrote in message <38B41432.88D7389F@quadruscorp.com>... > > >But I suppose those who would hang the moniker "hacker" upon themselves > >really want assembly language - only without the inconvenience of having > >to learn a new one every time new hardware comes out. Hence the > >popularity of things like C with hackers. > > > > > There even exists HLA (High Level Assembler) project which is nothing > more than new variation of C. > Intention is to use it instead of different assemblers. > Are you confusing the term HLA with that of High-Level Architecture, described in the following paragraphs from the project website? http://www.sisostds.org/stdsdev/hla/ If not, where can one get information about High Level Assembler? The High Level Architecture (HLA) has been developed with the objective of providing a common architecture applicable across all classes of simulation to support simulation interoperability and reuse. The HLA is defined by the following three draft standards: Framework and Rules - IEEE Standard P1516: The HLA rules describe the responsibilities of federates (simulations, supporting utilities, or interfaces to live systems) and federations (sets of federates working together to support distributed applications). The rules comprise a set of underlying technical principles for the HLA. For federations, the rules address the requirement for a federation object model (FOM), object ownership and representation, and data exchange. For federates, the rules require a simulation object model (SOM), time management in accordance with the HLA Runtime Infrastructure (RTI) time management services, and certain required functionality and constraints on attribute ownership and updates. Federate Interface Specification - IEEE Standard P1516.1: In the HLA, federates interact with an RTI (analogous to a special-purpose distributed operating system) to establish and maintain a federation and to support efficient information exchange among simulations and other federates. The HLA interface specification defines the nature of these interactions, which are arranged into sets of basic RTI services. Object Model Template (OMT) Specification - IEEE Standard P1516.2: The HLA requires simulations (and other federates) and federations to each have an object model describing the entities, not necessarily platform entities, represented in the simulations and the data to be exchanged across the federation. The HLA object model template prescribes the method for recording the information in the object models, to include objects, attributes, interactions, and parameters, but it does not define the specific data (e.g., vehicles, unit types) that will appear in the object models. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-24 0:00 ` David C. Hoos, Sr. @ 2000-02-24 0:00 ` Vladimir Olensky 0 siblings, 0 replies; 42+ messages in thread From: Vladimir Olensky @ 2000-02-24 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 30439 bytes --] David C. Hoos, Sr. wrote in message ... > >Vladimir Olensky <vladimir_olensky@yahoo.com> wrote in message >news:sb8gj38sr2a132@corp.supernews.com... >> >> Marin D. Condic wrote in message <38B41432.88D7389F@quadruscorp.com>... >> >> >But I suppose those who would hang the moniker "hacker" upon themselves >> >really want assembly language - only without the inconvenience of having >> >to learn a new one every time new hardware comes out. Hence the >> >popularity of things like C with hackers. >> > >> >> >> There even exists HLA (High Level Assembler) project which is nothing >> more than new variation of C. >> Intention is to use it instead of different assemblers. >> >Are you confusing the term HLA with that of High-Level Architecture, >described in the following paragraphs from the project website? >http://www.sisostds.org/stdsdev/hla/ Not at all. But I should admit that I was wrong that HLA is another version of C :-(. Something wrong switched on in my mind. HLA is some mix of different syntax features but it looks more like Ada than C. See below some notes where author explains why HLA looks more like Ada than C. Ada people would be pleased with that words. And that is just about "Why should hackers love Ada" :-) >If not, where can one get information about High Level Assembler? Pas de probleme. Below is what I've extracted from my archive. ================================================= From: Randall Hyde <rhyde@shoe-size.com> Subject: High Level Assembly FAQ Date: 9 ������ 1999 �. 6:58 ============================================================= The High Level Assembly Frequently Asked Questions (FAQ) List ============================================================= This document describes the HLA (High Level Assembly) language. Many of these questions were asked in newsgroups or email, some questions are simply "anticipated" questions injected to help describe the HLA system. -------- Purpose and General Questions ---------------------- 1: q. Where do you get a copy of HLA a. http://webster.cs.ucr.edu Following the High Level Assembly links. 2: q. What is HLA? a. HLA is a high level assembly language. It uses a high level language like syntax (similar to Pascal, C/C++, and other HLLs) for variable declarations, procedure declarations, and procedure calls. It uses a modified assembly language syntax for the standard machine instructions. It also provides several high level language style control structures (if, while, repeat..until, etc.) that help you write much more readable code. 3: q. Doesn't the presence of HLL control structures technically make HLA a high level language? a. These control structures are similiar to those provide by MASM and TASM (indeed, HLA's are weaker in some respects). So unless you're willing to call MASM and TASM high level languages, it doesn't make sense to call HLA a high level language. Definitely, though, HLA provides a syntax that is usually "higher level" that that provided by MASM or TASM (even in TASM's IDEAL mode). 4: q. HLA programs look like Pascal. Why didn't you make them look more like C/C++? a. Actually, they look more like Ada or Modula-2 than Pascal, but to answer the real question, Pascal is a much cleaner, easier to read language that C/C++. The intent was to create an assembly language that allows the creation of readable programs. The Pascal/Modula-2/Ada branch of the programming languages tree is generally acknowledged as producing more readable programs than the C/C++ branch. 5: q. But there are more C/C++ programmers today than Pascal programmers. Don't you think that using a C/C++ based syntax would have made HLA easier to learn by most people? a. No. HLA is only superficially related to Pascal. While Pascal programmers might have a tiny advantage when learning HLA, the majority of the learning effort is in other areas (like learning machine language) rather than learning Pascal's procedure declaration syntax vs. C/C++'s (about the only area where Pascal programmers have a real advantage). 6: q. Why is HLA necessary? What's wrong with MASM, TASM, GAS, or NASM? Do we really need another incompatible assembler out there? a. HLA was written with two purposes in mind: The first was to provide a tool that makes it very easy (or, at least, easier) to teach assembly language programming to University students. Experiences at UCR bear out the success of HLA's design (even with prototype/alpha code with tons of bugs and little documentation, students are producing better projects than past courses that used MASM). The second purpose was to provide a tool for very serious, code-quality-conscious programmers who want to write very powerful applications in assembly language (as opposed to the "DOS Hackers" who are still worrying about the fastest "sieve" program or the fastest integer to ASCII translation routine that can be written. What's wrong with MASM, TASM, GAS, and NASM? (a) Their very syntax encourages people to write unreadable programs (if you don't believe me, look at the code being posted to the net). (b) Their macro facilities are non-existent to moderate. They don't, for example support the creation of DSELs (domain specific embedded languages) very well. As to whether another incompatible assembler is good or bad, well, that toothpaste is already out of the tube and there is no putting it back. If you've got two incompatible assemblers, you may as well have three or four. Certainly, there was no good reason to attempt to make HLA compatible with an existing product. The whole point of HLA was to start fresh, not carry around a lot of old baggage from the late '70s (when Microsoft's first assemblers started appearing). 7: q. Is HLA intended for high level language programmers? a. Only in the sense that a HLL programmer who doesn't know assembly language will probably have an easier time learning HLA rather than, say, MASM. Otherwise, HLA is not intended for HLLs at all. While you can certainly write assembly language modules in HLA that link to other HLLs, HLA was specifically designed to let you write stand-alone application in assembly language under Win32. 8: q. HLA looks like BASM in Delph. What relationship does it have to BASM? a. None whatsoever at all. Indeed, HLA only superficially looks like BASM. Most likely, this confusion exists because HLA looks like Pascal. 9: q. HLA looks like it will save your students a lot of effort learning. Since the amount of information learned is usually directly proportional to the effort extended in learning the subject, don't you feel you are shortchanging your students by letting them use an assembler that requires less effort to learn? a. If I had a fixed amount of material to teach and I stopped once the material was covered, this observation would be correct. However, in the University I have a fixed amount of time for teaching, not a fixed amount of material to cover. By making the learning process more efficient, I can cover more material and get farther along in the same amount of time. 10: q. Students writing code with IF, WHILE, and FOR statements aren't writing true assembly language code. They are missing much of what assembly is about at that point. This isn't teaching assembly, this is teaching another mid-level language like C. a. This is true. A good instructor will not allow students to continue using HLA's high level language control structures throughout the term. However, they come in very handy at the beginning of the term because they allow students to write meaningful programs using a programming paradigm they already understand before they've had time to assimilate the entire instruction set. 11: q. Does HLA run under DOS? a. No. It only runs under Win32. 12: q. Does HLA run under Win 3.11? a. No. It only runs under Win32. That would be Windows 95, 98, NT, and 2000 (and probably later versions as well). 13: q. Why didn't you write it so that it runs under DOS? a. DOS is truly dead at this point. Most die-hard assembly language programmers still work in DOS because DOS is easy to program in assembly language and there is a large amount of programming information associated with DOS. A major point of HLA is that it is intended to make Windows programming as easy as DOS in assembly language. Currently, HLA does a good job of this with console apps. 14: q. Does HLA support console application programming? a. Yes. Very well. The console module in the HLA Standard Library is especially powerful. 15: q. Does HLA support graphics/GUI Windows application programming? a. There is nothing in the language that prevents you from writing graphical applications. At the current time, however, the HLA Standard Library doesn't provide much support for GUI apps. This will change with time. 16: q. Do you provide an application framework like OWL, MFC, or VCL for use with HLA? a. See the above answer. 17: q. Is HLA Shareware? a. No. HLA is free. 18: q. Is HLA GPL'd? a. No. You are free to do whatever you want with it. GPL puts a lot of restrictions on the code that I don't particularly agree with. 19: q. Is HLA public domain? a. No. I (Randall Hyde) retain the copyright. However, I allow you to distribute the release package with no restrictions whatsoever. 20: q. Is the source code available? a. Not yet. I am currently putting together a formal test suite for HLA and I don't want to release the source code until I get the product tested better. 21: q. Why not use the services of all the programmers on the net to test and debug your program, as has happened for Linux, NASM, and other Open Source projects? a. The HLA system is currently in excess of 100,000 lines of code. Part of this is due to inappropriate choice of programming language (FLEX/Bison), part of the size is due to sloppy coding, part of the size is due to the fact that HLA is a big language. I had to pull a lot of tricks with Flex and Bison in order to implement the language. The code is not easy to follow and easy to mess up if one isn't careful. It took me over three years to create this mess and I suspect it would take someone at least a year to figure out what I've done (never mind why I did it). By the time someone could really be providing useful help, I'll have the testing finished on my own. Then I'll release the sources. 22: q. Earlier you talked about writing readable code. Why didn't you follow your own advice on the HLA source? a. HLA is currently a prototype. A prototype is a program you write in order to test ideas out. I've been testing lots of ideas for over three years now. Many ideas have worked, many have failed, some have succeeded only through the application of brute force. However, the end result of all this experimentation is a grand kludge. The saying "always prepare to write your program twice, because you will..." certainly applies here. My prototype is the first version of the program. Version 2.0 will have to be a complete rewrite, applying what I've learned. 23: q. What are the other implications of a "prototype" piece of software? a. I don't have any problems changing the syntax of the language in such a way that it renders existing code uncompilable. I've done this on several occasions already, it will likely happen in the future. 24: q. What is the current version? a. The current version changes so often that any attempt to specify it here would produce something that is completely out of date. Go to Webster and you can find the latest version there. 25: q. You keep calling HLA a compiler. Aren't translators for assembly language called assemblers? a. In general, yes; HLA should be called an assembler. However, the internal design is that of a compiler rather than an assembler. Combined with the fact that HLA produces assembly code, not object code, the label "compiler" just seems to be a better fit. 26: q. What do you need in order to use HLA? a. You need to be running a Win32 OS. You need the HLA distribution package. You need MASM and a 32-bit version of MS-link. You also need some Windows DLL libraries like Kernel32.lib. All of these files are available free on the Internet. 27: q. Does HLA work with TASM? a. Kind of. The "m2t" (MASM to TASM) post-processor program converts the HLA MASM output to a form that will compile under TASM 4.0 (and later, hopefully). However, since MASM is freely available from Microsoft on the Internet, bother to use TASM seems hardly worthwhile. 28: q. Does HLA work with NASM? a. No. Feel free to modify "m2t" to produce "m2n", though. However, since MASM is *still* free, this doesn't seem worth the effort. 29: q. MASM is a disgusting assembler. Why do you force us to use it? a. MASM, NASM, GAS, or TASM. The choice is irrelevant since HLA automatically emits the MASM code, runs MASM, and links the code to produce an executable. You don't write MASM code and you don't run MASM. So unless you simply hate Microsoft and don't want to run the software they are giving you for free "just because," you don't have to worry about what assembler you're using. 30: q. Microsoft software is big and slow. Why force us to use it in order to use HLA? We'd prefer to use more efficient code. a. If you don't like MASM and LINK, you'll really hate HLA. MASM and LINK are faster than HLA. Remember, HLA is a prototype. No effort was made to make it efficient. --------- Language Specific Questions ----------------------------- 1: q. Could you give an example of a simple HLA program? a. Here's the HelloWorld program: program helloWorld; #include( "stdlib.hhf" ); begin helloWorld; stdout.put( "Hello World" nl ); end helloWorld; 2: q. Wait a second! There aren't any real machine instructions here! This isn't assembly language. a. Okay, here's the version in "real" machine code, still using HLA: program helloWorld; #include( "stdlib.hhf" ); static hw: string := "Hello World" nl; begin helloWorld; push( hw ); call stdout.puts; end helloWorld; Feel better? HLA lets you specify HLL-like procedure calls and it will automatically push the parameters on the stack for you. This is very similiar to the "invoke" statement MASM and TASM (although I personally feel that HLA's syntax is cleaner, clearer, and easier to read). If you really like, you can always explicitly write the assembly instructions yourself. However, there is little benefit to doing so. 3: q. Isn't it inefficient to pass parameters on the stack? a. In some cases yes. But if the procedure you're calling expects parameters on the stack, whether the compiler pushes them or you push them, there is hardly any difference. 4: q. The statement <<hw:string:="Hello World" nl;>> hardly looks like machine code, explain this. a. Note that <<hw byte "Hello World",13,10,0>> is no more a machine instruction than is the HLA declaration. Semantically, the two are equivalent and they generate nearly the same machine code (actually, HLA strings aren't simply zero- terminated arrays of characters; but ignoring that...). Syntactically, however, HLA turns out to be much easier to read. 5: q. Initialized data in the static section appears to be typed. What if I want to go wild and put untype, unstructured data into my program? a. Initialized data in the static section is indeed typed. You cannot initialize a string variable with a floating point numeric value (for example). However, HLA provides a second type of data initialization section, the "data" section, that allows the creation of unstructured initialized data. Since most data is structured, you will rarely use this feature in the language. 6: q. Why the parentheses around the push operand? a. HLA instructions are "composable". This means that you can often supply one instruction as the operand of another instruction. For example, consider the following statements: mov( 0, eax ); mov( eax, ebx ); These could be rewritten as: mov( mov( 0, eax ), ebx ); The interior mov instruction returns its destination operand for use as the operand the instruction represents. That is, HLA substitutes "eax" for "mov( 0, eax )" in the statement above. This funny looking statement generates exactly the same two instructions as the two separate mov instructions above it. 7: q. This doesn't look very readable. a. No, it is not. This feature needs to be used with extreme care or you can quickly produce an unreadable mess. However, composition of instructions is *very* useful in certain special cases. 8: q. The operands are backwards in your examples. a. No they are not. You're simply used to Intel syntax whose operands are generally orderd "instr dest, src". HLA reverses this order to obtain "instr( src, dest )" which is a little more intuitive for most instructions. 9: q. What happens with those instructions where the src,dest ordering is not intuitive? a. HLA uses dest, src ordering. The two primary examples are "cmp( dest, src )" and "lea( dest, src )". 10: q. Wait, this is horrible! You're saying that you're inconsistent with the order of the operands? a. No. Intel was inconsistent with the operands. They got lea and cmp right, almost everything else was wrong; at least if you consider the English pronouciation of the instruction to provide the "inituitive" ordering. We generally say "move source to dest", not "move dest from source". Likewise, we normally say "compare dest to source" (I can't even rephrase this with the operands reversed, forgive me). I usually say "load a register with an effective address." Hence the HLA syntax. 11: q. Your choice of the lea operand order is really bad. What if we say "load effective address into register." a. Fine, you can say that. I don't and I wrote the assembler so I got to choose. 12: q. That makes your assembler harder to learn. a. I disagree, but if you're really hung up on this *one* instruction (to date, no one has complained about cmp), you can easily write a macro to fix this problem. Consider the following macro for "sea" (store effective address): macro sea( source, dest ); lea( dest, source ) endmacro; Now your problems are solved. If you feel you must use the lea mnemonic, you've got two choices: (1) write a preprocessor to fix the syntax (very easy using HLA's pattern matching code) or (2) wait until the sources are available and change the source code. 13: q. Why didn't you use "sea" to begin with. a. For pedagogical reasons, I wanted to stick with instruction mnemonics that were upwards compatible with Intel's. As a new version of "Art of Assembly" using HLA is still quite a ways off, using Intel mnemonics allows students to look up an instruction by name and read about its semantics. True, the syntax is different, but providing a handout with HLA syntax is a much smaller task than providing a handout explaining what each instruction does. 14: q. Doesn't this (lack of good book explaining HLA syntax and semantics) make life hard on your students? a. Number one complaint. With time, this will go away (i.e., as I bring various chapters of AoA/HLA on-line. 15: q. Looking though the HLA documentation suggests that HLA supports instructions like "mov(mem, mem);", "pea( mem );", "mul( 10, ax );" These machine instructions do not exist on the 80x86. What's going on here. a. Although I made sure I supported almost all of the Intel instructions by name, by no means did I limit myself to only using Intel mnemonics. Once I covered the basic Intel instruction set, I took some liberties and added a few new instructions. mov( mem1, mem2 ), for example, compiles to push( mem1 ); pop( mem2 ); (this only supports 16- and 32-bit operands.) pea( mem ) compiles to push( eax ); lea( mem ); xchg( eax, [esp] ); and finally, "mul( 10, eax );" compiles to static tempName:dword := 10; endstatic; mul( tempName, eax ); 16: q. Isn't compiling code like this inefficient? a. If you abuse it, yes, there can be some slight inefficiencies. No one is putting a gun to your head and forcing you to use these new instructions or syntaxes, however. 17: q. MASM has a nasty habit of changing instructions behind your back. HLA also seems to have this same problem. a. Yes and no. Once again, if you stick to straight Intel instructions, HLA emits exactly what you specify. However, HLA emits MASM assembly code, so MASM may do a number on your code afterwards. In general, I have plans of adding a data flow analyzer and an optimizer around version three of HLA. While I certainly intend to provide source level control of the optimizer, if you are offended by an assembler that plays with your source code, then HLA is not for you. On the other hand, if you would like to be able to write readable code and leave it up to the compiler to deal with instruction scheduling and peep-hole optimizations, HLA will be a big win. 18: q. Does HLA support decent macro facilities? a. Yes. HLA supports the best macro facilities of any programming language I have personally seen. The macro facilities are so powerful, you can easily extend the language with it. For example, the HLA Standard Library includes a macro that provides a C/C++ style switch statement. Try doing that (easily and effectively) in MASM. 19: q. What high level language statements does HLA support? a. if..then..elseif..else..endif, while..endwhile, for..endfor, forever..endfor, foreach..endfor, repeat..until, break, breakif, continue, continueif, context..exit/exitif..endcontext, and try..exception..endtry. 20: q. What about statements like stdout.put("hello world" nl ); a. These aren't actually statements in the HLA language. Instead, these types of statements are either procedure calls or macros provided by the HLA Standard Library. The HLA Standard Library, and the way it extends the HLA language, provides a good example of the power of HLA's macros and HLL syntax. 21: q. Why doesn't the statement if( ax == bx && cx < dx ) then ... endif; work properly? a. HLA does not allow complex expressions like this. In particular, the conjunction operator ("&&") is not allowed here. 22: q. MASM allows this in it's .if statement. a. Yes it does. I chose not to implement this because HLA's HLL statements are intended as a crutch for students who are just learning assembly. However, I don't want the students writing arbitrary C/C++ programs in HLA. I want to force them to think in assembly rather than in C/C++. HLA's boolean expressions limit you to the types of operands that are legal in a compare instruction. This better prepares the students for when they have to use compares and conditional jumps in place of the HLL statements. 23: q. For those of us that are advanced and understand this conversion, this seems somewhat limiting. What if we want to use HLA's HLL control structures to write more readable code? a. HLA provides another syntax that lets you implement arbitrary expressions by combining HLL syntax with low level syntax. The previous example could be written as: if { cmp( ax, bx ); jne false; cmp( cx, dx ); jnb false; } . . . endif; The false label corresponds to the code after the "then" section of the if statement (though not present, the "true" label would transfer control directly to the "then" portion of the if statement). 24: q. Does HLA support classes and object oriented programming? a. Yes. It provides a very powerful class mechanism along with static class procedures, dynamic methods, and dynamic iterators. HLA support inheritence and many other features found in C++ and Delphi. 25: q. Do HLA procedure allow overloading? a. Not directly. However, you can easily use macros to provide any procedure overloading that you need? 26: q. Does HLA support operator overloading? a. Uh, no. Assembly language in general does not support run-time arithmetic expressions (which is where operator overloading makes sense). Hence the notion of operator overloading is foreign to HLA. 27: q. Doesn't HLA's HLL statements make the language inefficient? a. Not really. First of all, keep in mind that you don't have to use them. If you don't use them, they certainly won't affect the efficiency of your program Second, keep in mind that most HLL control structures compile to a cmp, a conditional jump, and, perhaps, a jmp instruction. Since this is exactly the type of code you'd probably write yourself, there is very little efficiency loss. Having said this, I should point out that anyone who approaches assembly language programming with a HLL mindset cannot expect to write super efficient programs. In order to obtain the benefits of assembly language, you need to think in assembly language. Using the HLL control structures relieves you of the need to think in assembly language. ---------------- HLA Standard Library Questions --------------------- 1: q. How to I write a procedure that converts a number to an ASCII string for output? a. You don't. Instead you should call one of the many Standard Library routines that will solve this problem for you. 2: q. What is the HLA Standard Library? a. It is a set of procedures you can call in your HLA programs. There are literally hundreds of routines you can call to accomplish many common tasks (for example, printing a number). 3: q. What library routines are available? a. The list appears at the end of this document (it's long!). 4: q. What are the categories these routines fall into? a. There are several categories, here's the current list (growing each week, so this is probably out of date): args- Command line argument parsing. console- Console window/smart terminal support routines. conv- Numeric/string and other conversions. cset- Character set functions. excepts- Exception handling. hla- Various constants, etc., for HLA compile-time language support (e.g., DSELs). hll- Macros to implement additional HLL statements. math- Transcendental and logarithmic functions. memory- Memory allocation and deallocation. misctypes- Various miscellaneous data type declarations. patterns- Pattern matching library (sorta like Snobol4/Icon). rand- Random number generators and support routines. stdio- Console and file I/O routines. strings- String library. Tables- Tables (associative array) library. win32- Win32 API constants and declarations. x86- Constants associated with Intel chips. WIP (work in progress, more to come later, including the full routine listing). ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-23 0:00 ` Why should hackers love Ada. (Re: Ada 95 based RTOS) Marin D. Condic 2000-02-23 0:00 ` Gary 2000-02-23 0:00 ` Vladimir Olensky @ 2000-02-24 0:00 ` Ehud Lamm 2000-02-24 0:00 ` Ted Dennison 2 siblings, 1 reply; 42+ messages in thread From: Ehud Lamm @ 2000-02-24 0:00 UTC (permalink / raw) On Wed, 23 Feb 2000, Marin D. Condic wrote: |But I suppose those who would hang the moniker "hacker" upon themselves |really want assembly language - only without the inconvenience of having |to learn a new one every time new hardware comes out. Hence the |popularity of things like C with hackers. | It is worth noticing that hackers also like VHLL, since they are interesting to play with. Scheme is well liked (though APL isn't. So it is tempting to see the "hacker attitude" as fashion?!) Hacking evolved through time. Today, I think coding in assembly is more the realm of what is known as 'Real Programmers" and not hackers. (Hope you are all familiar with the funny "Real programmers don't Eat Quiche" and its relatives) Ehud Lamm mslamm@mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm <== My home on the web Check it out and subscribe to the E-List- for interesting essays and more! ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Why should hackers love Ada. (Re: Ada 95 based RTOS) 2000-02-24 0:00 ` Ehud Lamm @ 2000-02-24 0:00 ` Ted Dennison 0 siblings, 0 replies; 42+ messages in thread From: Ted Dennison @ 2000-02-24 0:00 UTC (permalink / raw) In article <Pine.A41.3.96-heb-2.07.1000224095942.88252E-100000@pluto.mscc.huji.ac.i l>, Ehud Lamm <mslamm@mscc.huji.ac.il> wrote: > Hacking evolved through time. Today, I think coding in assembly is more > the realm of what is known as 'Real Programmers" and not hackers. > (Hope you are all familiar with the funny "Real programmers don't Eat > Quiche" and its relatives) If you're not, here are some from FOLDOC: Real Programmers Don't Use PASCAL - http://www.instantweb.com/foldoc/foldoc.cgi?Real+Programmers+Don't+Use+P ascal (Oddly, has a farily positive mention of Ada) The Story of Mel, a Real Programmer - http://www.instantweb.com/foldoc/foldoc.cgi?The+Story+of+Mel Reading both of these lengthy but entertaining tales will give a very good idea of what is meant by "Real Programmer". -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Ada 95 based RTOS 2000-02-23 0:00 ` Tarjei T. Jensen 2000-02-23 0:00 ` Gautier @ 2000-02-23 0:00 ` Ted Dennison 2000-02-25 0:00 ` Scott Ingram 1 sibling, 1 reply; 42+ messages in thread From: Ted Dennison @ 2000-02-23 0:00 UTC (permalink / raw) In article <890ght$bih1@ftp.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: > > If your read (and believe) what the Jargon file > (http://www.tuxedo.org/~esr/jargon/) writes about Ada then it is not You shouldn't. This has come up before. ESR is not particularly Ada friendly, and his jargon file is mainly his feelings on the defnitions of things. He's a clever guy, but he doesn't know everything. So the stuff in the jargon file is often quite off the mark. I much prefer to refer people to FOLDOC ( http://foldoc.doc.ic.ac.uk/foldoc/mirrors.html ), which takes submissions from anyone. Its much more comprehensive, better maintained, and wittier. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Ada 95 based RTOS 2000-02-23 0:00 ` Ada 95 based RTOS Ted Dennison @ 2000-02-25 0:00 ` Scott Ingram 0 siblings, 0 replies; 42+ messages in thread From: Scott Ingram @ 2000-02-25 0:00 UTC (permalink / raw) Ted Dennison wrote: > > In article <890ght$bih1@ftp.kvaerner.com>, > "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: > > > > If your read (and believe) what the Jargon file > > (http://www.tuxedo.org/~esr/jargon/) writes about Ada then it is not > > You shouldn't. This has come up before. ESR is not particularly Ada > friendly, and his jargon file is mainly his feelings on the defnitions > of things. He's a clever guy, but he doesn't know everything. So the > stuff in the jargon file is often quite off the mark. > > I much prefer to refer people to FOLDOC ( > http://foldoc.doc.ic.ac.uk/foldoc/mirrors.html ), which takes > submissions from anyone. Its much more comprehensive, better maintained, > and wittier. > > -- > T.E.D. > > http://www.telepath.com/~dennison/Ted/TED.html > > Sent via Deja.com http://www.deja.com/ > Before you buy. Also note the interesting Ada entry in the "Super Linux Encyclopedia" at http://smalllinux.netpedia.net/links/ada.html. Its well done, neutral, and provides links to all of our favorite sites. -- Scott Ingram Sonar Processing and Analysis Laboratory Johns Hopkins University Applied Physics Laboratory ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2000-03-11 0:00 UTC | newest] Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-02-18 0:00 Ada 95 based RTOS xaplos 2000-02-18 0:00 ` Tucker Taft 2000-02-21 0:00 ` xaplos 2000-02-22 0:00 ` Matthew Majka 2000-02-22 0:00 ` xaplos 2000-02-22 0:00 ` Ted Dennison 2000-02-22 0:00 ` xaplos 2000-02-23 0:00 ` Roger Racine 2000-02-24 0:00 ` Simon Wright 2000-02-24 0:00 ` Robert Dewar 2000-02-25 0:00 ` Mike Silva 2000-02-26 0:00 ` xaplos 2000-02-22 0:00 ` Marin D. Condic 2000-02-22 0:00 ` Stanley R. Allen 2000-02-23 0:00 ` Tarjei T. Jensen 2000-02-23 0:00 ` Gautier 2000-02-23 0:00 ` Ehud Lamm 2000-02-23 0:00 ` Why should hackers love Ada. (Re: Ada 95 based RTOS) Marin D. Condic 2000-02-23 0:00 ` Gary 2000-02-24 0:00 ` Gisle S�lensminde 2000-02-24 0:00 ` Marin D. Condic 2000-02-24 0:00 ` Larry Kilgallen 2000-02-25 0:00 ` Gary Scott 2000-02-25 0:00 ` Marin D. Condic 2000-02-25 0:00 ` Gary 2000-02-25 0:00 ` Mike Silva 2000-02-26 0:00 ` Gary Scott 2000-02-26 0:00 ` Robert Dewar 2000-02-26 0:00 ` Gary Scott 2000-03-07 0:00 ` Mike Dimmick 2000-03-10 0:00 ` Wil 2000-03-10 0:00 ` Ada OS again " David Starner 2000-03-11 0:00 ` David Botton 2000-02-23 0:00 ` Vladimir Olensky 2000-02-23 0:00 ` Gautier 2000-02-24 0:00 ` Ehud Lamm 2000-02-24 0:00 ` David C. Hoos, Sr. 2000-02-24 0:00 ` Vladimir Olensky 2000-02-24 0:00 ` Ehud Lamm 2000-02-24 0:00 ` Ted Dennison 2000-02-23 0:00 ` Ada 95 based RTOS Ted Dennison 2000-02-25 0:00 ` Scott Ingram
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox