INFO-ATARI16 Digest Thu, 2 Nov 89 Volume 89 : Issue 597 Today's Topics: Am I a DA? (long) Congratulations (was: GEMDOS Extended Argument Spec) GNU C and sizeof(int) GNU C and SOZOBON C LHARC Source wanted! Naive Question : ST & IBM Disk Compatibility Ramblings of a madman (Sozobon C topics) ---------------------------------------------------------------------- Date: 1 Nov 89 19:51:32 GMT From: imagen!atari!kbad@ucbvax.Berkeley.EDU (Ken Badertscher) Subject: Am I a DA? (long) Several people have asked me recently how to write a program so that it could be used as both a desk accessory and as a program. The problem is not too hard, but requires some mucking about with the startup code of the program - if you're not willing or able to do that, then you needn't read any further... Still with me? Okay, the key to identifying whether your code is running as a DA or a program is the parent basepage pointer in the basepage. If the longword in the basepage at offset 36 (0x24) - which points to the basepage of whatever launched your code - is NULL (0), then your code is running as a DA. The problem is that a DA does not get a pointer to its basepage on the stack like an application does. In fact, a DA's registers (including the stack pointer!) contain garbage on startup, which is the reason that a DA must set up its own stack straight away. The startup code provided with some compilers includes code which checks whether the parent basepage pointer is null or not. This code usually gets around the aforementioned problem of locating the basepage by taking advantage of the way the system normally loads DAs and programs. The TPA (Transient Program Area, i.e. text, data, BSS, and stack/heap) of a program or DA is normally contiguous with its basepage in memory. All the startup code has to do is look back 256 bytes from the start of the text segment, which is the first part of the TPA, and voila! There's the basepage. The operative word here is "normally." It is not entirely safe to assume that your program's basepage is contiguous with its TPA, because it is possible for a program to set up a non-contiguous basepage and TPA by using the more arcane Pexec() modes. If you must assume that the basepage and TPA of your program are contiguous, then your startup code should validate that the basepage it is using points to a contiguous basepage and TPA. If the basepage and TPA are contiguous, then the longword located 256 bytes before the text segment will point to itself, since the first longword of the basepage points to the base of the TPA. Ideally, you should even go a step further, and check the text base address. The third longword in that basepage should match your startup code's base address. There is an alternative method which is not used by any startup code of which I am aware. This method will allow the same code to run as a program or as a DA, and will also allow it to run with a non-contiguous basepage and TPA. It also takes advantage of the way the system "normally" does things, but we can guarantee that the system will always do things this way. I mentioned before that a DA's registers are garbage on startup, well, that's not entirely true. When the DA gets control, register A0 always points to its basepage. When a program is started by a GEMDOS Pexec(), register A0 is always cleared. Using this fact, it is possible to implement startup code which gets the basepage address from register A0 if the code is launched as a DA, or at 4(sp) if the code is launched by Pexec(). Since it knows how it was launched, it can also do the stack setup required of a DA, otherwise it can use the stack pointer it gets. I strongly recommend that startup code implementors use the latter method of DA/program startup. It allows far more flexibility in Pexec implementations, it works just as well as the "text base minus 256" method, and it is supported by Atari. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include ------------------------------ Date: 2 Nov 89 19:30:11 GMT From: ubc-cs!grads.cs.ubc.ca!buchanan@beaver.cs.washington.edu (John Buchanan) Subject: Congratulations (was: GEMDOS Extended Argument Spec) In article <1763@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes: > >GEMDOS EXTENDED ARGUMENT (ARGV) SPECIFICATION > >Introduction This is what we have being waiting for. Nice to hear an OFFICIAL word about this whole mess. WELL DONE ATARI. ------------------------------ Date: 2 Nov 89 17:58:11 GMT From: watmath!rbutterworth@iuvax.cs.indiana.edu (Ray Butterworth) Subject: GNU C and sizeof(int) In article <1754@ruuinf.cs.ruu.nl> piet@cs.ruu.nl (Piet van Oostrum) writes: >Dlibs and Gemfast have been written for a 16 bit compiler. >I have a version of Dlibs that I adapted for use with GCC. >It has been modified for 32 bit integers. This reminds me of something I've been wondering about for a while. Why does GCC on the ST have 32 bit ints? Surely 16 is the obvious size considering it has 16 bit memory access. (Note that I don't consider "so that badly written code will still work ok" as a valid reason.) Every time anything accesses an int in CGG, it requires two memory accesses. Most programs are full of things like "++i" or "i+=7" or "if(i>j)", and such things take approximately 100% longer when ints are 32 bits. Even worse, take a look at the source for functions that interface with the OS. Typically the function has a loop that takes the 32-bit ints from the stack and moves them to 16-bit words and then invokes the system trap with a pointer to this list. Surely it would be many times faster with 16-bit ints, since the function could simply pass a pointer to the stack arguments without having to do any of the moves and resizing. Has anyone made a 16-bit GCC and library and done a comparison? ------------------------------ Date: 31 Oct 89 17:09:53 GMT From: gem.mps.ohio-state.edu!samsung!shadooby!mailrus!jarvis.csri.toronto.edu!utgpu!w atmath!ria!uwovax!7103_300@tut.cis.ohio-state.edu Subject: GNU C and SOZOBON C In article <4830@sdcc6.ucsd.edu>, pa1329@sdcc13.ucsd.edu (pa1329) writes: > 1. Can the GNU C complier use dlib and gemfast bindings for writing > TOS and GEM programs? > The new GCC library (distributed with versions 1.34 and later) is partly based on dlibs, and partly on other PD routines. The intention was to provide the maximum degree of portability with UNIX and MS-DOS systems. I think it succeeds quite well; I've used the GCC to port dozens of applications (including NetHack 3.0) with remarkably little effort. There is a GEM library available for the GCC, which seems fairly complete; I can't recall if it was based on gemfast or not. There's also a port of Berkeley's curses package (you can't get much more portable than that :-). All this stuff is available by anonymous FTP from dsrgsun.ces.cwru.edu (129.22.16.2) and probably from other archive sites as well. (Of course, source code is available for everything.) DISCLAIMER: I'm biased; I helped put together the library, and wrote some of the routines. What I didn't like, I fixed... Eric Smith ersmith@uwovax.uwo.ca ------------------------------ Date: 2 Nov 89 03:08:57 GMT From: rochester!rit!ultb!ajy2208@pt.cs.cmu.edu (A.J. Yarusso) Subject: LHARC Source wanted! Help! ===== I am looking for the sources to LHARC, if they are in the public domain... LHARC is very slow and a bunch of us here in Rochester would love to re-write. Rest assured that this will be the first place an improved version of LHARC would appear, so any help I receive in getting the source will benefit you too (in the long run).... Thanks, (keeping my fingers crossed that LHARC is public domain).. _____________________________________________________________________________ Albert Yarusso, Rochester ajy2208@ritvax.bitnet, ajy2208@ultb.rit.edu Institute of Tech. _________________________________________________________ Computer Science /___ / ?rutgers, ames?!rochester!ritcv!ajy2208 ______________________/ / ajy2208@ritcv.cs.rit.edu GEnie: A.Yarusso ------------------------------ Date: 2 Nov 89 17:08:24 GMT From: e2big.dec.com!ynotme!wallace@decuac.dec.com (Ray Wallace) Subject: Naive Question : ST & IBM Disk Compatibility In article <1989Nov1.232645.9023@agate.berkeley.edu>, ladasky@codon3.berkeley.edu (John Ladasky;1021 Solano No. 2;528-8666) writes... >but when I went to the PC on campus that is hooked in to the network, it >wouldn't read it! DCFROMAT will also make a ST floppy useable on a PC. Don't use folders on the disk as this causes problems sometimes. If formatting on the ST doesn't work try formatting it on the PC (format for DD not HD, ie: 726kb not 1.44mb or whatever the exact # is) and then put it in the ST to copy the files onto. I've had luck using DCFORMAT on the ST, writting the files on a Tandy PC, then reading the files on the ST. Some combinations work for some people other combinations for other people (or machines). The best you can do is try a few different things and hope one way eventualy works for you. Good luck, --- Ray Wallace (INTERNET,UUCP) wallace@oldtmr.enet.dec.com (UUCP) ...!decwrl!oldtmr.enet!wallace (INTERNET) wallace%oldtmr.enet@decwrl.dec.com --- ------------------------------ Date: 2 Nov 89 08:02:10 GMT From: thelake!steve@UMN-CS.CS.UMN.EDU (Steve Yelvington) Subject: Ramblings of a madman (Sozobon C topics) In article <8911011638.AA18226@ucbvax.Berkeley.EDU>, S61304@PRIME-A.POLY-SOUTH-WEST.AC.UK (Rat) writes ... >Having just read a message in Vol. 89 Issue 565 questioning whether there is a >shell available for Sozobon C, I would also like to second this question! > >I am starting my final year project using Sozobon C and would find a shell >_VERY_ useful, espesially if it can handle environment variables. Sozobon C works perfectly well with Un*x-style shells, such as Gulam, tsh, etc. I use jShell, which perhaps John Stanley will someday quit making perfect and post. :-) But I suppose you're looking for a GEM shell for Sozobon C. I worked on one for a month or two. A number of factors stopped me: * I'm not good enough at programming to make a "gee-whiz" graphic compiler shell -- something like Think C on the Macintosh. This is a hobby. I don't do this for a living. * I got involved in other projects, namely some Usenet netnews software. * I didn't find it useful. The last point is probably the most important. I really didn't see much use for GEM in the write-compile-link-test cycle. Working from a command line is a lot more convenient. I'd rather type "cc fubar.c" than point-click-point-click-point-click-point-click-knock-over-my-coffee-cup. If you disagree, I'd like to hear why. What do you expect to get out of a compiler shell? What sort of user interface do you envision? I might be persuaded to dredge up my SeeShell code and start hacking at it again. Or maybe you'll be inspired to write your own. -- Steve Yelvington, up at the lake in Minnesota ... pwcs.StPaul.GOV!stag!thelake!steve (UUCP) ------------------------------ End of INFO-ATARI16 Digest V89 Issue #597 ***************************************** =========================================================================