Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!bionet!ames!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.sys.apple2 Subject: Re: a2fx/hfslink Message-ID: <14040@smoke.BRL.MIL> Date: 7 Oct 90 07:37:45 GMT References: <9010051457.AA18841@apple.com> <1990Oct6.051920.4341@utstat.uucp> Organization: U.S. Army Ballistic Research Laboratory, APG, MD. Lines: 21 In article <1990Oct6.051920.4341@utstat.uucp> philip@utstat.uucp (Philip McDunnough) writes: >While I'm at it, are there any ANSI Basic languages for the GS? What >about Orca/C? Does it follow (strictly) the ANSI C standard? I haven't heard much demand for ANSI BASIC; on the other hand, ByteWorks now has an implementation of Apple Integer BASIC for the (compiled) ORCA environment; it's said to be much faster than AppleSoft (interpreted). There have been a couple of other commercial BASIC compilers released, one from Beagle Brothers, and one from Apple sold via APDA. Morgan Davis also has an MD-BASIC that you might be interested in. ORCA/C attempts to mostly follow the C standard, but it falls short in several areas; for example its preprocessing is not a full implementation, and it is missing the internationalization support. It also still (as of release 1.1) has quite a few bugs, so you have to use it with a suspicious mind. Make sure your code is strictly conforming, and if it malfunctions, examine the code that the compiler generated then devise workarounds for the bugs. For example, I recently discovered that unsigned_long-1 had code generated that evaluated instead unsigned_long+1, at least when used as an array subscript; casting the unsigned_long to int worked around this particular compiler bug (at least, for values that fit within an int).