dougm@pnet51.orb.mn.org (Doug Mcintyre) (10/17/90)
MQUINN@UTCVM.BITNET writes: >On Mon, 15 Oct 90 07:15:43 GMT Collin Broad Douglas said: >> >>Can anyone make suggestions on development software? I think I'm going >>to get Orca/C, Orca Pascal and Orca assembler. Maybe after I learn a lot, >>I can join FTA. > >I highly recommend the ORCA/M Assembler. In my opinion, Assembly Language >(or C) is the best way to go... but I can't recommend any good C compilers >for the GS, because I've never used one. I can't recommend any good C compilers, because I *have* used all of them. UUCP: {rosevax, crash}!orbit!pnet51!dougm Compuserve: 70611,2215 ARPA: crash!orbit!pnet51!dougm@nosc.mil ALPE: DougMac INET: dougm@pnet51.cts.com GENIE: D.MCINTYRE1
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (10/18/90)
dougm@pnet51.orb.mn.org (Doug Mcintyre) writes: > I can't recommend any good C compilers, because I *have* used all of >them. Come on, you're not being fair. ORCA/C will be a pretty decent compiler when they get the $!@#$ bugs out and finish making it ANSI compliant. Todd Whitesel toddpw @ tybalt.caltech.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/18/90)
In article <1990Oct17.181845.7369@nntp-server.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes: >Come on, you're not being fair. ORCA/C will be a pretty decent compiler when >they get the $!@#$ bugs out and finish making it ANSI compliant. While it's usable as of release 1.1, so long as one is constantly aware of the likelihood of genuine compiler bugs (as opposed to programmer misexpectations), ByteWorks has essentially just one technical employee (Mike Westerfield), and he tends to work primarily on one product at a time. Thus, until ORCA/M 2.0 and the next upgrade of ORCA/Pascal are released, ORCA/C will very likely remain in the state that it is now in.
eldorado@en.ecn.purdue.edu (David D Jansen) (01/09/91)
I am in the market for a good C compiler. Currently I have HyperC but it just doesn't cut the mustard. It does not support real numbers (except through sane functions). I want a compiler that runs under the Prodos system, compiles to assembly and will then be able to run under Prodos. The object code must be independent of the compiler environment. I want to be able to write editors, printer drivers, modem drivers, etc so it must be flexible. I want to convert my fractal program to C and then be able to run the object code with a "brun fractal" at the prompt. I have heard of Aztec C and ORCA/C could you give me some input? Basically the C must be as close to standard as possible. Dave -- I am not really here. _______________________________________________________________________________ Dave Jansen | INTERNET: eldorado@en.ecn.purdue.edu
ericmcg@pnet91.cts.com (Eric Mcgillicuddy) (01/09/91)
You can still get Aztec C, but the Prodos version is in the neighbourhood of $300. I'm not sure that it is worth it since Manx is not supporting their Apple II products any longer. Orca/C is fine if you have a GS and are writing for a GS. I not sure the system which you are writing for, but I assume it is 8-bit Apples. Basically, you are stuck with HyperC. You might consider rewriting the Linker (no I don't have source for the linker), I have no idea how difficult this would be, but there are likely a number of people that would be interested. Personally, I don't see the problem with including the compiler with your program, you will be using a fair portion of it in most serious programs anyway. UUCP: bkj386!pnet91!ericmcg INET: ericmcg@pnet91.cts.com
ST6934@SIUCVMB.BITNET (01/10/91)
There's a Small(sp?) C available for the prodos 8 Orca/M version 4.1 that's published by Byteworks and distributed by APDA; it's listed in the last catalog of products I received from them. Andy. ST6934@SIUCVMB
toth@tellabs.com (Joseph G. Toth Jr.) (01/10/91)
In article <363@generic.UUCP>, ericmcg@pnet91.cts.com (Eric Mcgillicuddy) writes: [Aztec C stuff deleted] > Basically, you are stuck with HyperC. You might consider rewriting the Linker > (no I don't have source for the linker), I have no idea how difficult this > would be, but there are likely a number of people that would be interested. Re-write the Linker??? Why in the world would anybody want (or need) to do that?? It has worked just fine for for every compile i have performed. There do seem to be some problems with the mac codes that convert P-code to 6505 (65c02 ??) assembler.. This seems to be the area where Mr. Michael Pender was having problems when using floating point operations. I tried the examples he posted, and they bombed horribly when compiled to native code, but executed perfectly when I compiled to P-code. I guess this could still be a linker problem, but I have too many other pieces of code, compiled to native code, that work just fine (no linker problems). The only difference is that none of them use the floating point operations. Joe Toth Tellabs, Inc. Lisle, Il. -- ------------------------------------------------+--------------------- Maybe I shouldn't have done it, sarcasm is so | Joseph G. Toth Jr. seldom understood. Don't FLAME on me, please. | uunet!tellab5!toth
ericmcg@pnet91.cts.com (Eric Mcgillicuddy) (01/14/91)
>> Basically, you are stuck with HyperC. You might consider rewriting the >Linker >> (no I don't have source for the linker), I have no idea how difficult this >> would be, but there are likely a number of people that would be interested. > >Re-write the Linker??? Why in the world would anybody want (or need) to do >that?? It has worked just fine for for every compile i have performed. Rewriting the Linker is required to generate stand alone SYS applications under prodos. HyperC assumes the OPSYS file to be present during execution and links it in as a runtime library (soft links?). If OPSYS is not present, then the linker must attach all of the functions normally provided by it. Native compiles do not need the p-code interpreter, so this could be discarded, but otherwise, most of OPSYS will be used by most applications. Floating point is handled by SANE, I have no idea why they do not work under native compiles. Have you tried the log.c example included on the /fp disk? See if this works. UUCP: bkj386!pnet91!ericmcg INET: ericmcg@pnet91.cts.com
greyelf@wpi.WPI.EDU (Michael J Pender) (01/15/91)
In article <5017@tellab5.tellabs.com> toth@tellabs.com (Joseph G. Toth Jr.) writes: >Re-write the Linker??? Why in the world would anybody want (or need) to do >that?? It has worked just fine for for every compile i have performed. > >There do seem to be some problems with the mac codes that convert P-code >to 6505 (65c02 ??) assembler.. > >This seems to be the area where Mr. Michael Pender was having problems when >using floating point operations. I tried the examples he posted, and they >bombed horribly when compiled to native code, but executed perfectly when >I compiled to P-code. > >I guess this could still be a linker problem, but I have too many other pieces >of code, compiled to native code, that work just fine (no linker problems). >The only difference is that none of them use the floating point operations. Why don't people tell ME these things :^) I'll have to try that. Actually to create a native code object file, compile to native code and use the -a, -s and -h directive to make addresses absolute, I forgot what s is for and -h removes the header. The problem then is that display routines in conio are not included with your program. Just rename your file shell, and pack the files c.system/gs.system opsys and shell on the same disk. Besides the Pcode is fast enough for most uses. Its not worth the extra disk space. Mike.
toth@tellabs.com (Joseph G. Toth Jr.) (01/16/91)
In article <378@generic.UUCP>, ericmcg@pnet91.cts.com (Eric Mcgillicuddy) writes: > >> Basically, you are stuck with HyperC. You might consider rewriting the > >Linker > >Re-write the Linker??? Why in the world would anybody want (or need) to do > >that?? It has worked just fine for for every compile i have performed. > > Rewriting the Linker is required to generate stand alone SYS applications > under prodos. HyperC assumes the OPSYS file to be present during execution and > links it in as a runtime library (soft links?). If OPSYS is not present, then > the linker must attach all of the functions normally provided by it. This isn't necessarily so.. I guess things never are as simple as they sound, but rewriting the linker would only be the beginning of more and possibly bigger problems. Remember; P-code object files and Native code object files link together and execute fine. The 'BRK' 6502 op code invokes the interpreter for code immediately following the break (until the P-code routine returns). How many (anybody care to guess??) supplied routines are written using P-code? How many were compiled (My guess is none, [scan the SYM output])? How many are compiled using the assembler? People sharing code (who don't wish to part with source) could post linkable objects (ie. a 'curses' set of functions in a library), where some object files are P-code. Try linking and executing those without the 'opsys' ;^). One option would be a program that in some way converts any executable into a new file that contains both the opsys (modified to not load 'SHELL', then execute the shell as if it were loaded) and the target executable (at the appropriate location). This would eliminate any potential problems of linking objects of differing types. It would also be possible to simply change the filetype of the HyperC executable to SYS, and then overwrite the lead in code (prior to the first 6502 code in the s.o file) with NOPs. This would require a re-write of the s.o object file to perform all appropriate tasks (pseudo stack init, I/O buffer inits, etc) previously handled by opsys. Also, many system functions (printf, xprintf, alloc, free, file I/O, [many more]) that were anchored to opsys, will have to be supplied. Luckily, once they are made available, simply replacing the objects (which contain anchoring information) in the LIBC library will cause no linker problems. One other problem with links that can be native code only.. The floating point package has major problems when compiled to native code, but seems to operate OK (in the checks I have done) when executed as P-code elements. > Native compiles do not need the p-code interpreter, so this could be > discarded, but otherwise, most of OPSYS will be used by most applications. Remember, just because you compiled something into a native code object, don't assume that everything you link to is native code also (:^j) > Floating point is handled by SANE, I have no idea why they do not work under > native compiles. Have you tried the log.c example included on the /fp disk? > See if this works. Seems to be more inSANE when compiled to native code ;^) Question; Does c.system (and gs.system) actually overwrite a portion of its own code with opsys, and then fall into it (opsys) via normal execution? -- ------------------------------------------------+--------------------- Maybe I shouldn't have done it, sarcasm is so | Joseph G. Toth Jr. seldom understood. Don't FLAME on me, please. | uunet!tellab5!toth