Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!rice!titan!phil From: phil@titan.rice.edu (William LeFebvre) Newsgroups: comp.sys.amiga.tech Subject: Re: assembly lang questions: frame pointer, ROMWack, A68K, etc Summary: Thanks, and here's more info Message-ID: <2220@kalliope.rice.edu> Date: 27 Nov 88 15:36:56 GMT References: <2206@kalliope.rice.edu> <11737@cup.portal.com> Sender: usenet@rice.edu Reply-To: phil@Rice.edu (William LeFebvre) Organization: Rice University, Houston Lines: 96 I have also received several replies by mail. Thanks everyone. I neglected to elaborate on my setup, which I will do later in this note. In article <11737@cup.portal.com> nop@cup.portal.com (Randy G Jouett) writes: >>On most other systems (such as Unix), there is a convention that a6 is the >>"frame pointer"....Is there a convention used for the frame pointer? >>Or is it just any register you want? > > You can use the "link An,#n" instruction on all of the address >registers, except for a6...and a7, of course. Well, that's not quite what I was after. I wanted to know if there was an unwritten convention about the frame pointer. Others have told me that there is not. Use anything you like, just make sure you put it back when you are done (unless it's a0 or a1, of course). >>Other than the "preserve d2-d7/a2-a7" convention, are there any other >>assembly language conventions I should be paying attention to? > > Yes. Do not use the "move #n,SR" instruction.... That's more than a convention (and I knew about that one already). That's a necessity. >>Are there any known bugs in ROMWack? [stuff rm'ed for bandwith.] Turns out there is a bug with the '[' code. Mail me if you want details. >>Am I doing something wrong, or is A68K notoriously slow?> > > I don't use A68k, and you didn't mention your environment or source >size, so I'll venture to say that this is way to long. Okay, I forgot to elaborate on my setup. I'm on a (68000) B2000 with two floppies and 3 meg total of ram. I run FACCII. I'm using the "A68K" assembler originally written by Brian Anderson and converted to C and AmigaDOS by Charlie Gibbs. It is version 1.02 (Sept. 9, 1987). I am also using the stripped version of the includes (no comments). The program that I am working on is only 436 lines long. But it includes intuition.i (among a few other things) and when all is said and done, the assembler has to process over 3500 lines. But it still takes on the order of 5 minutes even with everything loaded into the floppy cache (i.e.: minimal disk activity). So I know that it isn't the floppy that's slowing it down. It is almost certainly the 3000 lines or so of included text that slows me down. So I ask again, is there any shortcut I don't know about? I know that at least one of the compilers has precompiled include files. That's kind of what I'm after. I will also try putting the include directory into RAM: (still 1.2) and see if that makes things any faster. This program also has the annoying habit of telling me what line of source it is on. This is only annoying because it updates this information every 10 lines. Lesee, that's 5 characters per update, 300 updates, and two passes: 3000 characters that get written to the console during the assembly. I suppose that might also be slowing it down. I'll try redirecting that elsewhere. >>I'm working on a little helper program for browser users. Stay tuned for >>details. I hope to have it ready after thanksgiving break (when I'll have >>some time to finish and polish). Maybe I can pay a little back to the >>Amiga community that has given me so much (browser, Dmouse, DME, ConMan, >>etc.). > > Send the details! Okay. It's called "fileinfo" and is designed to be used as a Browser "tool". You select a file in Browser and invoke the tool. It then pops up a window with all the useful information from the file info block about that file (size, date, protections, comment). I got tired of hunting down a CLI every time I wanted to know how big a file was. Version 2 will let you change things as well. Note that this is not the same as Workbench's "info" item. This works with any file and doesn't even think about dealing with the "DiskObject" structure (tool types, etc.). The window is also much smaller. Once I add CLI command line parsing, it will even be useful from the CLI for examining and changing a file's characteristics in a user friendly way. I suppose it could even be useful directly from the Workbench, since it lets you examine and change more characteristics than "info". It's not much of a grand program, but it is a start. And it will be written all in assembler (I'm too cheap to buy a C compiler, and assembly language is more fun anyway...besides, I'm a masochist, remember?). It should work under 1.3, but it (at least initially) won't know about the new protection bits. That should be a short-term problem as I intend to order the new includes RSN. Sound interesting? Project #2 is an Intuition interface to Dmouse's options, so that one may change the paramters from the Workbench. I've looked at Dmouse and decided that this is easy. The hardest part is coming up with a good user interface. This one is still stuck in my brain---nothing on disk just yet. William LeFebvre Department of Computer Science Rice University