From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,76da32d8c4934801 X-Google-Attributes: gid103376,public From: smize@news.imagin.net (Samuel Mize) Subject: Re: Ada --> C Translation, was: Win CE target Date: 1998/10/14 Message-ID: <702jg1$gst$1@prime.imagin.net>#1/1 X-Deja-AN: 401033878 References: <6u6flv$qn7$1@nnrp1.dejanews.com> <6vobnk$vt9$1@jupiter.cs.uml.edu> Organization: ImagiNet Communications Ltd, Arlington, Texas Reply-To: smize@imagin.net (Samuel Mize) Newsgroups: comp.lang.ada Date: 1998-10-14T00:00:00+00:00 List-Id: In article <6vobnk$vt9$1@jupiter.cs.uml.edu> dramirez@cs.uml.edu (Dr Amirez) writes: > ... If you consider a feature rich language a better language > then let me tell you this. I remember seeing a question on this forum > that goes like this: "If a task blocks on I/O, do other tasks get a chance > to run or the *process* will suspend itself, and no task will run > until the process get scheduled again? " > Someone responded that it's undefined. Well, I would think such > an important feature should be very well defined instead of being > left as an excercise for the user to find out how that is implemented > on their systems. By golly, he's right. we should pick one way and stick to it. If somebody needs a different one later, he can make up his own darn language. Seriously, I/O blocking is only ambiguous for the predefined I/O packages, which are convenience packages. Ada was originally defined for embedded systems. If I'm building a real-time simulator, or an embedded radio system, or a crypto module, I really don't care whether Text_IO blocks the process or not. I'm never going to use it anyway, I'm going to be watching I/O ports with machine-specific code. Also, if I recall correctly, this WAS defined for Ada 83, by implication at least[1]. In Ada 95 the situation was improved by making it LESS defined. This lets vendors offer more options, and makes it cheaper to put Ada on new targets. Your discussion seems to assume this model for development: 1. Get compiler 2. Write program 3. Find out how compiler implements critical features The Ada community tends to put step 3 before step 1. Actually, though, much of the commercial C community uses your model. They buy a box, and they use whatever compiler came with the box. Why, of course you use the vendor's C compiler -- how else do you get all their system-specific libraries? But, of course, those aren't actually part of the language, so it's OK for their definitions to wander all over the map. > You can't program systems using features that are system dependant > themselves. I see. That must be why most of the system code I've seen is shot through with IFDEFs like cancer. You tell the compiler or make utility which versions of all the system calls you have available, and it tries to assemble a version of the program that will work. The Ada approach is to start by selecting a compiler that does what you need. Both approaches work. Neither works with the other technology. > The more features a language has, the more flaws it has. You, as an > Ada programmer, probably know better than I. I assume you're saying that a more complex system has more opportunities for bugs[2]. However, that argument ignores the fact that these language features replace user-written code. Ada was designed to provide features that most embedded systems already had, but which were hand-built in system after system. Most of the embedded community's programs need some form of multi-tasking, for example. It's a LOT less error-prone to have one implementation of tasking, that gets exercised by hundreds of projects, and that everyone tests the BLEEP out of. You wind up with a very solid tasking implementation. The alternative gives you a very simple language, everybody implements tasking separately (costing a small fortune), and lots of bugs wind up in delivered systems. By the way, Dr Amirez, my news feed doesn't seem to pick you up -- I'm replying to another reply to your post -- so please email me if you reply. Thanks. Best, Sam Mize [1] A lower-priority tasks's processing -- even a system call -- should not block a higher-priority task that becomes ready. Some implementations failed to get that right, and it wasn't tested by the validation suite, so some compilers that blocked on I/O got into the community. Which is why you heard the question at all. [2] I'm assuming this meant "You, as an Ada programmer, probably know this even better than I do." However, I won't ARGUE with the statement as written. :-) -- Samuel Mize -- smize@imagin.net (home email) -- Team Ada Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam