[comp.sys.apple] GEnie ORCA/C Roundtable discussion

numccann@PLAINS.NODAK.EDU ("Lester I. McCann") (07/09/89)

Here's the GEnie transcript of the discussion with Mike Westerfield on the
subject of ORCA/C.  Beware:  there are some loooooong lines in these GEnie
transcripts!

Lester McCann (numccann@plains.nodak.edu)

 ------------------------------------------------

  Apple II Programmers and Developers RoundTable
  ==============================================

        Real Time Conference Transcript
        -------------------------------

 Guest  : Mike Westerfield
        : The Byte Works
 Date   : June 19, 1989

 Copyright 1989 GEnie         All rights reserved
 ------------------------------------------------

<[Eric] A2PRO.ERIC> I'd like to thank everyone for coming to the conference tonight. Our guest is Mike Westerfield, of The Byte Works. ORCA/C started shipping last week and should be a very exciting development language... I am still at Jay's house and haven't seen my copy yet <grin>, but I'm REALLY excited about playing with it later tonight. At the end of the conference, we'll be giving a copy of ORCA/C away to a randomly selected person here in the conference room.

<[Mike] BYTEWORKS> (papers shuffle, members of the press raise their hands...) Hi folks!

As an introduction to ORCA/C, I wanted to answer the three most often asked questions about our C:

1.  How fast does it compile? (Generally compared to APW C.)

Any line-per-minute measure is just eye-wash. I can manipulate those numbers until they mean nothing. Let's compare it to APW C to get a good idea: on average, compiling seven short to medium size benchmarks, APW C takes about 1/3 longer to compile a program, and about 6 times longer to link a program. The overall difference to turn a program around is a factor of 7.41.

2.  How big is the code? (Again, generally compared to APW C.)

Our library overhead for a small program like hello world that uses printf is about 3K. In fact, hello world is 12 bytes over 3K. Similar sized APW C programs are about 22K.

On our seven standard benchmarks, the difference in code size ranged from a factor of 2.67 on the sieve, where most of the program is a large array that is the same size in both programs, to 6.91. The average was 5.03. As programs and arrays get larger, the difference does get smaller, but even the code produced by ORCA/C is generally smaller than the code produced by APW C.

3.  How hard is it to port programs from other compilers?

ORCA/C implements ANSI C, and there are some compatibility issues to keep in mind when porting programs. In the programs we have ported, there are two major areas of concern:

a.  Malloc. malloc doesn't even exist in ANSI C. We have implemented it as a macro to help you port programs. Under ANSI C, malloc takes a long argument.  (Actually, it's size_t, which is an unsigned integer big enough to hold a pointer.  That makes it long in ORCA/C.) If you religiously use your interface files (malloc is in stdlib.h), the conversion from short to long is automatic.  If you don't, the program will fail.

b.  Sizeof as a parameter. The sizeof function returns an int in pre-ANSI C.  It returns a long now. That causes problems for non-prototyped functions that use sizeof to compute a parameter. (Prototyped functions have the argument converted automatically.)


The important features of ORCA/C are:

1.  The source level debugger.
2.  You can choose between a text or graphics environment.
3.  It is easy to mix C and assembly - and an entire chapter in the manual
    shows you exactly how.
4.  Our manual shows you how to write programs for each of the GS environments,
    including CDAs and NDAs.
5.  ORCA/C is compatible with the latest draft ANSI standard.

Now, on with the questions!

<[Eric] A2PRO.ERIC> How long does the introductory price on ORCA/C last for current ORCA/M owners?

<[Mike] BYTEWORKS> I think the official expiration is August 1st, but if you're real nice, we'll go longer. ;)

<[Floyd] FLOYD.ZINK> Hi, Mike! Did you give any consideration to some sort of pre-compiled headers to speed compiles?

<[Mike] BYTEWORKS> Yes, but technically, they are illegal in C. The problem is that you can redefine the meaning of a .h file by changing the definition of a macro before the file is included. For a good example, see assert.h, where that is the norm, rather than the exception. We have thought about it, though, and have come up with some thnings to do in the future.

<[Floyd] FLOYD.ZINK> Thanks.

<[Toolworks] M.MANYEN> Mike, are you REALLLY shipping? I order on 6/5 and have not received it yet. Also, how much of a hassle will it be to convert from APW C??

<[Mike] BYTEWORKS> Yes, we are REALLLY shipping! All orders were shipped as of last Friday; it did take a while to catch up to the backlog. As for how hard it will be to convert APW C programs, it depends on the program. The major areas we have seen problems with were addressed in the opening remarks. Do you have specific questions? Did you miss those? (I could replay them...)

<[Toolworks] M.MANYEN> No, I got the opening in buffer... I just wanted to get an idea I have a REAL large APW c program and wanted a general idea of what I have in store for me.

<[Mike] BYTEWORKS> The biggest problems have to do with changes in the language since APW C was written. The two biggest of these are malloc and sizeof, both of which use long values now, and used to use int values. If you use interface files, the problems will be masked by the prototypes for the functions. If not, you will have some problems to track down.

<[Lance] LLPROD> Mike, two questions. First, how much will it cost me to upgrade ORCA/M and ORCA/Pascal and buy ORCA/C?? Second, has anyone tried to port over C code written in ORCA/C to another platform (IBM) and if so, was it easy?

<[Mike] BYTEWORKS> It depends -- what versions of ORCA/M and ORCA/Pascal do you have? (The price depends on whether you need a new manual.)

<[Lance] LLPROD> Old versions of M and Pascal....first revs...

<[Mike] BYTEWORKS> The price for ORCA/C for owners of either Pascal or ORCA/M is $75. The price for an upgrade from ORCA/Pascal (desktop) or ORCA/M with a manual is $15; for pre-desktop Pascal, I _think_ the price is $30, but I will have to check with Patty. She could give you the straight poop if you call her at 505-898-8183, or if you leave the version #s and which manuals you need in a mail message, I'll get back to you.

<[Lance] LLPROD> I'd like to get C and upgrade them all....just need an amount. Ok, I'll call tomorrow.

<[Lorne] L.WALTON> Any problems linking with MERLIN 16+'s modules?

<[Mike] BYTEWORKS> I don't know. We don't try compatibility testing with Merlin... sorry. If they are properly using OBJ files, there will be no problems. If not, you might try a real assembler. (duck) Also... I missed part of a previous question. We have not tried porting from ORCA/C to other compilers, but that should not be difficult. If the other compiler is not ANSI C, you should stay away from prototypes and other extensions; if it is ANSI C, the prot should be easy.

<[Lorne] L.WALTON> Thanks. If Merlin isn't a REAL assembler, I guess I don't want a REAL one.

<[Mike] BYTEWORKS> ;)

<[Lorne] L.WALTON> Are there a lot of changes from the Kernighan standard?

<[Mike] BYTEWORKS> Yes - quite a few. The nicest is function prototyping, which allows the compiler to check to be sure you are passing the right number/type of parameters. The changes to sizeof and malloc are a bit annoying, and there are other changes in the libraries, too, but overall they were needed.  Incidentally, there is a K&R 2nd ed. that covers ANSI C. If you like K&R, I recommend it. I also recommend Harbison & steele, 2nd ed.

<[Lorne] L.WALTON> Thanks, Mike.

<[ Bill ] W.TUDOR> Hello Mike, and welcome to our RTC. I bought APW C a few months back and I frankly haven't used it much for development primarily because of its seed, so I am very happy about your product. My question is this: will there be any incentive (other than ORCA's obvious superiority) for APW-C owners to convert over...i.e., a discount?

<[Mike] BYTEWORKS> Frankly, no. To make something like that work, we would need to get a copy of the owners of APW C. If I could get THAT... but that's another story.

<[ Bill ] W.TUDOR> OK, I have a final comment. Let's all stay away from assembler-bashing tonight. The development community needs competition in this area to keep you guys making the good products! That's all, thanks.

<[Shawn] S.QUICK1> Is ORCA/Desktop included with ORCA/C? And, give us three reasons why we should switch from APW C to ORCA/C....this is a free chance for you to do some selling! :)

<[Mike] BYTEWORKS> 1. Yes, ORCA/Desktop is included with ORCA/C.  And that (and the fact that there is a source level debugger) is one good reason.

2. ORCA/C is ANSI C. While a few pre-ANSI programs may be a bit hard to port, the changes are for the most part welcome. Things like prototyping change the nature of the language.

3. ORCA/C compiles faster than APW C, and links _much_ faster.

4. (can I keep going?) ORCA/C code is much smaller than APW C code.

5. ORCA/C programs run faster than APW C programs.

6. ORCA/C has a choice of two excellent environments, while APW C doesn't come with one at all -- it costs extra.

<[Shawn] S.QUICK1> I don't think Merlin is capable of creating OBJ type files
100%. Maybe you could answer this for me....is it possible to create "true" OBJ files from actual object code, with just a list of external and internal labels?

<[Mike] BYTEWORKS> It may be possible, but I wouldn't want to try it. I really thought that Merlin _did_ create true OBJ files, at least as an option. If not, you might contact Roger Wagner, 'cause he told me it did.

<[Shawn] S.QUICK1> Well...I don't believe you could. For example, LDA #label-anotherLabel.

<[Mike] BYTEWORKS> With due respect to Merlin, then, try ORCA/M or APW. If you are mixing languages you may find them easier.

<[ Andy/OKS ] CBG> Mike, I didn't have a chance to ask this at AppleFest, and in the literature I received at work (thank you) it mentioned that some unix-specific runtime library routines were omitted. Which ones? I guess I ask specifically, can I use Orca/C to write a program launcher with the exec() or spawn() calls?

<[Mike] BYTEWORKS> You can't use spawn -- that is tied to multi-tasking, and those were the ones we removed. I don't think exec is standard C, that's unix specific, but there is an equivalent in ORCA/C. It's called... oh, heck. I can't find it right now. It's in the manual. I'll look it up later, if you like.

<[ Andy/OKS ] CBG> Grin... equivalents I can live with. #define exec(parms) equivalent(parms). Sounds like a great product.

<[Dave] NY.SOFTWARE> Is ORCA/C for GS/OS or will it run under ProDOS 16?

<[Mike] BYTEWORKS> ORCA/C is for GS/OS. The compiler itself is generic, but the libraries do use GS/OS calls.

<[ Andy/OKS ] CBG> Will the compiler generate an assembly language source file?

<[Mike] BYTEWORKS> No. It does have a built-in mini-assembler, but it does not generate assembly source. By the way... to answer your previous question, the call is system(). For example, system("catalog\r"); will catalog a disk.

<[ Andy/OKS ] CBG> Great!! So system("/HD/GAMES/TETRIS/TETRIS") will launch Tetris, and system("/HD/ORCA/UTILITIES/VIEWPIC picname") will launch a shell app?

<[Mike] BYTEWORKS> You've got the right idea, but the current shell is a bit picky about that trailing \r. More to the point, though, is that you can do anything that could be done from a script file, like setting shell variables, or writing a 'make' program with little effort.

<[ Andy/OKS ] CBG> But only under the shell, I assume.. correct?

<[Mike] BYTEWORKS> True.

<[ Andy/OKS ] CBG> Okay... great!

<[ Dave_E ] DDELY> What kind of System 5.0 upgrade are you planning?

<[Mike] BYTEWORKS> That depends a lot on how many/how severe the bugs we get are. At a minimum, the system 5.0 upgrade will have all of the new interface files. It will probably have a new version of the compiler, libraries & interface files to fix bugs, and perhaps to add a few features and library calls. Ask me again as 5.0 gets closer to release.

<[ Dave_E ] DDELY> Ok, what's the story on APW macros? Are they included now or later, or what?

<[Mike] BYTEWORKS> APW macros have nothing to do with C. APW macros are currently shipped with ORCA/M, and are also available as an upgrade for $3 to current ORCA/M owner.

<[ Dave_E ] DDELY> Ah, I missed the point. I thought perhaps you were including a library for easy APW C conversion. Sorry.

<[Mike] BYTEWORKS> We licensed the APW C tool libraries to make conversions of APW C programs (and back) easy.

<[Dave] NY.SOFTWARE> Me again. Is ORCA/Pascal GS/OS only, or will it run under ProDOS 16? I have a very full HD of pre-GS/OS stuff.

<[Mike] BYTEWORKS> ORCA/Pascal will currently run under either ProDOS 16 (from system disk 3.2) or GS/OS. That will not always be true.

<[Dave] NY.SOFTWARE> Great. I am cleaning up the system, waiting for system disk 5.0.

<[Eric @ Jay's] A2PRO.ERIC> I was wondering if you could explain the SYSTEM() function some. Can it be used from a standalone program? Or is it just to talk to the shell?

<[Mike] BYTEWORKS> The system function is used in ANSI C to call the shell. You can type any shell command, up to and including entire script files, and send them to the shell from an executing C program via the system call. Since the system call is dependent on the host shell, C programs that use the system call are not, of course, stand-alone applications; they can only be executed from the shell.

<[Eric @ Jay's] A2PRO.ERIC> Hmmmmmmmm.... I think I understand. Very interesting. What kind of demo programs does ORCA/C come with? How many?

<[Mike] BYTEWORKS> I don't remember the number. There is a clock NDA, two CDAs, a frame desktop program (explained in full detail in the manual), a simple CAD program developed from the FRAME program, a complete REVERSI game, several benchmarks, a number of text and graphics programs that illustrate various special tricks and techniques, and several programs taken from the user manual. The user manual has a very long chapter reviewing the various programming environments, telling you what programming consi


derations you need to keep in mind, and in most cases, presenting several samples line-by-line, explaining how they work.

<[Eric @ Jay's] A2PRO.ERIC> Wow, it should be great! I'm really looking forward to playing with it tonight.

<[Mike] BYTEWORKS> Be sure & read the release notes!

<[Eric @ Jay's] A2PRO.ERIC> Will do! <grin>

<[Jock] JOCKC> Having arrived recently, I have some basic questions that might have been answered. First, how many dhrystones (I love raw bench comparisons!)?

<[Mike] BYTEWORKS> I didn't run that particular benchmark. Here's a few others (these are all from Byte, and are also on our disk):

        Float.CC:           84.53 sec. (SANE stinks)     APW C:  94.99
        15000 GAMM units:   33.33                        APW C:  35.17
        Sieve:               6.29                        APW C:  16.64
        QuickSort:          50.30                        APW C:  58.12
        Savage:             70.96                        APW C:  71.63

<[Mike] BYTEWORKS> If you are interested in floating point, though, buy an FPE card. With the FPE card, the results are: Savage: 0.50; Float: 2.18; GAMM: 1.96.

<[Jock] JOCKC> For the most part, those times are only slightly better. What about object (run file) size?

<[Mike] BYTEWORKS> The times that are only slightly better are from programs that spend virtually all of their time in SANE (GAMM, FLOAT, SAVAGE) or in integer math calculations (QUICK). The PRIME benchmark is the only one that spends most of it's time in code created by the compiler. The comparison there was 6.29 to 16.54. As for code sizes, the average for the benchmarks quoted was 5.03 times smaller. The smaller the program, the bigger the difference. 

<[Jock] JOCKC> I understand the SANE problem, that's one good thing about the Dhrystone bench. It does a lot of various housekeeping type things glad to see object size reduced. APW was ridiculous. What about compile/link times?

<[Mike] BYTEWORKS> It takes a HUGE amount of housekeeping to make up for the slow speed of SANE. That's why I said that if you want to do floating point, get an FPE card.

<[. Ron .] MICOL.SYSTEM> Agreed... get an FPE card.

<[Mike] BYTEWORKS> Compile times are about 25% faster than APW C on average, while link times are about 6 times faster. The overall difference for a compile and link is a factor of 7.41.

<[Jock] JOCKC> Great. How about the text environment? The old Orca/M assembler editor is a bit anemic compared to say, vi. And going from /bin/sh at work to the shell script of orca is hard to do... comments?

<[Mike] BYTEWORKS> If you _really_ want vi, download it. I think there is a vi clone here somewhere. As for the shell, there are going to be differences. We are not a UNIX subset. We are more of an MPW subset, and getting closer all the time.

<[Jock] JOCKC> I supposed recompiling microemacs with Orca/c should satisfy me.
Load times for the APW uEmacs were terrible due to size. That's all the questions for now, thanks!

<[Mike] BYTEWORKS> You're right... it was Emacs, not vi, that I was thinking of.

<[Kevin] K.FLYNN> Earlier you mentioned that there was a "system()" call. Does that require the ORCA shell or will it work with any shell that supports passing commands to it? (my lack of APW knowledge shows) 

<[Mike] BYTEWORKS> It should work with any shell, but it must support the EXEC call a 'la APW and ORCA/M. Are there any like that out there?

<[Kevin] K.FLYNN> Don't know... thanks.

<[Eric @ Jay's] A2PRO.ERIC> For what it's worth, Merlin does it a little differently than APW/ORCA/M... Okay, We're giving away a copy of ORCA/C. Here's how it works:

<[. Ron .] MICOL.SYSTEM> <--- crossing my fingers

<[Eric @ Jay's] A2PRO.ERIC> I use GEnie's dice rolling commands to roll a single sided die with as many sides as users here now. You must be present to win, and only paying users are eligible. There's 18 people in the room right now. The winner is John Samples, job #3. {Note - although it doesn't show in this transcript, I rolled GEnie's electronic dice to come up with the number 3.}

<[Jock] JOCKC> The dice was loaded.

<[Dave] NY.SOFTWARE> Rats...I never win.

<[Eric @ Jay's] A2PRO.ERIC> Congratulations!

<[Pete/PC/GSBG] P.CHIN> Yeah.

<[Mike2] M.ENARSON1> Curses!!

<[-=-Marty-=-] M.KNIGHT> Congrats, John!

<[Jock] JOCKC> Typical. I thought since I just bought ORCA/C, I'd be sure to win a free copy.

<J.SAMPLES> Thanks.

<[Mike] BYTEWORKS> John, can you e-mail me your mailing address? And congratulations!

<J.SAMPLES> Mike, quick, tell Barbara to cancel my order!

<[Mike] BYTEWORKS> :) Will do...unless it's been mailed already. If so, we'll work it out. John, send us a mailing address or a daytime phone number. The rest of you can buy yours now. ;) Incidentally, for you price-conscious shoppers who don't have an ORCA product yet, try the mail-order houses. They offer very good discounts, and all are now stocked.

<[Eric @ Jay's] A2PRO.ERIC> Mike, where can we get it from? What's your address and phone number?

<[Mike] BYTEWORKS> Byte Works, Inc.
                   4700 Irving Blvd, NW, Suite 207
                   Albuquerque, NM  87114
                   (505) 898-8183

Major mail order houses now stocked: Golum Computer, Triad, Tech Alliance, Programs Plus. Thanks for having me, all!

<[Eric @ Jay's] A2PRO.ERIC> Clap clap clap!

<[Kevin] K.FLYNN> <applause><applause>

<[Jerry] A2.JERRY> <whistle> <loud cheers>

========================= End of Transcript ==========================

Permission is hereby granted to not-for-profit user groups to reprint
this transcript in its entirety, provided that this notice is included.

To sign up for GEnie, follow these simple steps:

1.  With your computer and modem, dial 1-800-638-8369.

2.  When you connect, type HHH and hit the RETURN key.

3.  The computer will type U#=.  You respond with XJM11706,GENIE.

4.  Now answer the questions and you will be able to use GEnie the next
working day.  Be sure to have a credit card or checking account number
handy when you sign up.

----------------------------------------------------------------------