long@sask.UUCP (Warren Long) (10/08/87)
Well, recently I decided to pull my 'SpaceWar' out of the dust, and see about a few more modifications. Since I now use MWC 2.0 (instead of Megamax), I thought I should get it working with MWC. Most changes were trivial, but the resultant code took 44K, instead of about 33K, for the SAME program. I find this a little alarming. That is a very substantial increase. While trying to clean up some glitches, I discovered that using 'fopen/fgetw', while working with Megamax, would not work with MWC. A few random substitutions of a pair of 'getc' for each 'fgetw' made the whole thing work. I have no idea how this could affect anything. I am open to suggestions/hints. This did make the program run identically to the one produced with Megamax. BOTH sets of spaceships were glitched identically. I was hoping for the glitches to disappear, then I could blame the compiler. What I did try was to use 'Fopen/Fread'. This fixed all my little glitches. Now that I think about it, I have been having lots of strange things happenning with (little)fopen/getc etc. Is this a known problem?? Have I been struggling with a well-known bug?? Other comments: I have been trying to adapt some Megamax code which used in-line assembly code. To use MWC, I separated out the assembly code into individual little routines, and tried to get every thing to compile. HOW DO I TELL THE ASSEMBLER THE ADDRESS OF VARIABLES IN MY C-PROGRAM?? It is easy with Megamax in-line code, just use the variable's name. Help! Comment on MSH: Has anyone gotten the aliasing to work? I can type in their example 'set in .cmd lc="ls -l"', and it works just fine. But when I try to do something more useful, I can't get it to work. For example, 'set in .cmd cds="cd d:\sw"', does not result in my CD-ing to the appropriate directory. Can someone offer a hint?? Thanks for letting me ramble... Warren Long -- =-=-=-=-=-Warren Long at University of Saskatchewan, Canada-=-=-=-=- Home: 78 Carleton Dr.,Saskatoon, Sasakatchewan, S7H 3N6 Phone: (306)-955-1237 =-=-=-=-=-U-Email: ...!ihnp4!alberta!sask!long -=-=-=-=-=-=-=-=-
braner@batcomputer.tn.cornell.edu (braner) (10/11/87)
[] My guess is that MWC made the program larger since all references to variables and functions, i.e. all addresses, are 32-bit instead of the 16-bit offsets used by Megamax. Many people have complained about the 32K limits in Megamax, enough that the upcoming Megamax 2.0 will have 32-bits throughout. But that means larger, and slower, executables. BTW, this is very different from the infamous "segmentation" IBM-PC users have to deal with. Even in Megamax, all pointers are 32 bits, so that pointer arithmetic works fine for large chunks of RAM. It's just that a reference to a variable looks like: a = b; --> move b(A4),a(A4) p = &a; --> lea a(A4),p(A4) or lea a(A4),Rp if p is a register variable. Here 'a' and 'b' are 16-bit numbers. A4 is set at runtime, when the program is launched, so Megamax code is basically position-independent. The new version, with absolute addressing, will be relocatable (as all GEMDOS programs are) but not position-independent. The above lines will look like: move a,b move #a,p where a,b,p are absolute addresses. (In reality, expect to see things like: move b(A4),D0; move D0,a(A4) lea a(A4),A0; move.L A0,p in the 16-bit case, etc. A compiler just needs to do a lot of optimizations to approach AL... I DID observe Megamax to translate "*p++ = *q++" (with register pointer vars) into "move (Aq)++,(Ap)++". I hope for more such smarts!) - Moshe Braner
root@uop.UUCP (S. User) (10/12/87)
Well, the size isn't _really_ the compiler's fault. Just a different design methodology: the Megamax produces PC-relative code and the Mark Williams produces _real_ code. That is why there is the 32k limitation on Megamax programs. To use variables in MWC, pass them as parameters. Everything is passed as a long word. so func(v1,v2,v3,v4) char v1; short v2; int v3,v4; ends up like this on the stack: (sp) Return Address from the jsr 4(sp) v1 (use move.b 4(sp), d0 or equiv) 8(sp) v2 (use move.w 8(sp), d0 or equiv) 12(sp) v3 etc 16(sp) v4 etc If you use the link instruction (as in compiled C-code), then make sure you allow for the address it'll push onto the stack and the instructions effects. G. Onufer
root@uop.UUCP (S. User) (10/12/87)
Sorry, but I left a few things out... If you write assembler routines that return values, the result has to be stored in D0. (If it is a struct, then the address of the struct; same with strings and arrays [same thing anyways]). Aliases in MSH I think are run like programs. The current working directory will be restored after the alias is finished. It way work if you set the MSH variable 'pwd' to whatever you want it to be. Use GULAM instead... it is a lot nicer than MSH. Works better with most GEM programs too. G. Onufer
pett@cgl.ucsf.edu (Eric Pettersen%CGL) (10/16/87)
In article <879@sask.UUCP> long@sask.UUCP (Warren Long) writes: >Comment on MSH: Has anyone gotten the aliasing to work? I can type >in their example 'set in .cmd lc="ls -l"', and it works just fine. But >when I try to do something more useful, I can't get it to work. >For example, 'set in .cmd cds="cd d:\sw"', does not result in my >CD-ing to the appropriate directory. Can someone offer a hint?? I spent a long time trying to get a csh-like pushd/popd alias to work and concluded that msh must execute these aliases in a subshell, leaving the parent shell unaffected. About the best you can do if you have an unbearably long path that you frequently type is to set a shell variable equal to it (in, say, .profile) and just say "cd $x", for example. Eric Pettersen UCSF Computer Graphics Lab pett@cgl.ucsf.edu or ucbvax!ucsfcgl!pett
dag@chinet.UUCP (Daniel A. Glasser) (10/17/87)
Some comments on the findings which may have already been made: 1) Program size Not only does the MWC image have absolute refs instead of using PC/register relative addressing only as in MegaMax, but the symbol table is stored in the image file by the linker. This symbol table can be removed with the strip program. Before comparing program sizes, strip the MWC image file. 2) MSH "alias": MSH in fact treats the ".cmd" buffer as a directory, and each command in it is considered to be a file. Executing one of these 'files' happens in a subshell. Since .cmd is not a real directory, you cannot use the . command to execute in the current shell. If you have some commands that you want to execute which affect the shell or environment, put them in a file that can be found along the search path, and then use the "." command, so: (file \bin\work) cd e:\working\dir ; lc *.c can be executed by . work when this is done executing, your current directory will be e:\working\dir (assuming it exists, and that \bin is in your search path.) Non-Disclaimer: I do have association with Mark Williams Co., and although these are not official remarks, if you were to call and ask, you would get the above answers. 3) GULAM I've never used GULAM, but I will try and find a copy and look at it. Who produced it? Is source available? If someone knows these things, please send me E-mail, since I doubt that everyone wants this info. -- Daniel A. Glasser ...!ihnp4!chinet!dag ...!ihnp4!mwc!dag ...!ihnp4!mwc!gorgon!dag One of those things that goes "BUMP!!! (ouch!)" in the night.