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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,984e922902f4f4ee X-Google-Attributes: gid103376,public From: "Marin David Condic, 561.796.8997, M/S 731-96" Subject: Re: Can Ada by popularized faster ? Date: 1997/10/13 Message-ID: <97101319252965@psavax.pwfl.com>#1/1 X-Deja-AN: 280450542 Sender: Ada programming language Comments: To: bpr@shell5.ba.best.com X-VMS-To: SMTP%"INFO-ADA@VM1.NODAK.EDU" X-VMS-Cc: SMTP%"bpr@SHELL5.BA.BEST.COM",CONDIC Newsgroups: comp.lang.ada Date: 1997-10-13T00:00:00+00:00 List-Id: > Brian Rogoff writes: >Right. I think the SBC market is interesting from an Ada point of view. >What are the main CPUs being used? Is a bare bones Ada compiler available >for it? > Well, for starters, almost any compiler that would be considered suitable for the SBC market would hardly be considered "bare bones." The quality of the code that comes out of it must be extremely efficient and highly reliable. Even a minor inefficiency starts to multiply rapidly in a chunk of code that runs once a milisecond. Any compiler bug that produces bad code creates the possibility of an error escaping into the field which can be *very* costly. So just the compiler itself has to be above and beyond what one might find acceptable, say, for teaching computer programming using an MS-DOS based computer. P.S. I am assured by folks who should know that there is no need to trim the Ada standard in order to get Ada to fit inside some of the small microprocessors in question. (At one time, yes, but compiler technology has improved considerably.) Then, because you're going to a bare piece of hardware without the luxury of an OS, you've got to have a cross-linker that darned well better be able to give you real good control of where anything and everything goes in memory and it has to be able to tell you reliably what it actually did. Surprises aren't fun! It needs to output IEEE symbol tables, Motorola S-Records and/or similar load formats. You need some kind of ability to load code into the card - which gets real dependent on the architecture of the card. We typically use a real time monitor of our own design that goes into startup ROM and communicates with a chunk of software on the host system which acts as our loader and our debugging system. You've got to have all of that just in order to play the game. We aren't even yet talking about bells and whistles. As for target processors, our engine controls are designed around things like the 68040 - where processor selection had to take into account availability of an Ada compiler. But there are lots of small jobs, custom one-offs, test hardware, etc. where things like the 68HC11 on an off-the shelf board makes the most sense. Micronix makes a nice little board based on this processor. Z-World sells a fair number of Z180 based SBCs. EMAC is another company with similar machines. Check out the web pages to get a flavor of what they're building with: http://www.emacinc.com/ http://www.zworld.com/ http://www.agt.net/public/micronix/ http://www.claritech.demon.co.uk/ Lots of companies make cards based on 80x86 processors, but these tend to be PC compatible computers which run some real time version of MS-DOS and tend to want to communicate with devices as separate cards - whereas the type of machine I'm interested in is the kind of thing that has one or more A/D-D/A converters a handful of discretes, a serial link and that's about it. I have not heard of any Ada compilers targeted to 68HC11, Z180, 8051, 68HC16 or other processors you see on the web pages of the SBC manufacturers. That doesn't mean there aren't any - just that a) the SBC manufacturers aren't hawking one along with their development kit and b) nobody has brought to my attention any third-party solutions. It might not do any good simply to have, for example, a port of GNAT to one of these machines unless you could provide simultaneously all the related software that has to work with the output of GNAT. As you can imagine, that's not a trivial request. MDC Marin David Condic, Senior Computer Engineer Voice: 561.796.8997 Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600 Fax: 561.796.4669 West Palm Beach, FL, 33410-9600 Internet: CONDICMA@PWFL.COM =============================================================================== "Eagles may soar, but a weasle never gets sucked up into a jet engine." ===============================================================================