phil@rice.edu (William LeFebvre) (11/23/88)
I have a few questions regarding assembly language programming on the
Amiga. Mucho thankso to those who can take the time to answer them for me.
On most other systems (such as Unix), there is a convention that a6 is the
"frame pointer". It always points to the last call frame. In other
words, most subroutines start out with "link a6,..." and end with
"unlk a6". But it seems that on the Amiga, a6 is conventionally used to
hold the library base address for library calls ("move.l _DOSBase,a6 ...
jsr _LVOUnLock(a6)"). Is there a convention used for the frame pointer?
Or is it just any register you want? Other than the "preserve
d2-d7/a2-a7" convention, are there any other assembly language conventions
I should be paying attention to?
Are there any known bugs in ROMWack? The RKM:Exec makes no mention of any
limitations on the '[' command, making me think that I can nest '['
commands arbitrarily. I would think I could at least nest them 2 deep.
But the second '[' gives me a guru very consistently. Even when the
memory location is in a reasonable place (i.e.: definitely fast ram).
What gives?
Am I doing something wrong, or is A68K notoriously slow? I'm talking
upwards of 5 minutes for an assemble. Now, my program does include
'intuition.i', which is very large and includes about 50 other files, but
it still seems to take too long. Is there a shortcut I can use with
equivalence files or something?
Why oh why are the definitions in 'exec/types.i' IN ALL UPPER CASE?
(I'm sure there's a good reason).
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.).
William LeFebvre
Department of Computer Science
Rice University
<phil@Rice.edu>ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (11/24/88)
In article <2206@kalliope.rice.edu> phil@rice.edu (William LeFebvre) writes: >Are there any known bugs in ROMWack? [ ... ] Well, I know it doesn't work on a 68020. It's neat; your program Gurus, then you hit the right mouse button to enter ROMWack to debug it, and it comes back with a completely different Guru. Rinse. Repeat. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
nop@cup.portal.com (Randy G Jouett) (11/25/88)
>I have a few questions regarding assembly language programming on the >Amiga. Mucho thankso to those who can take the time to answer them for me. Your welcome :) >On most other systems (such as Unix), there is a convention that a6 is the >"frame pointer". It always points to the last call frame. In other >words, most subroutines start out with "link a6,..." and end with >"unlk a6". But it seems that on the Amiga, a6 is conventionally used to >hold the library base address for library calls ("move.l _DOSBase,a6 ... >jsr _LVOUnLock(a6)"). 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 (Well, you could even use a6, but you better make damn sure that you unlk it and put a valid base pointer in a6 before making a system library call :>) and a7, of course. You will also have to make sure that you don't walk over a4 (global) or a5 (stack frame) when writing hybrid code using Manx; I'm not sure if this is true with Lattice, though. >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. The 010 (68010) will blow groceries if it sees this :) >Are there any known bugs in ROMWack? [stuff rm'ed for bandwith.] I don't use ROMWack, myself -- can't help here. >Am I doing something wrong, or is A68K notoriously slow? I'm talking >upwards of 5 minutes for an assemble. Now, my program does include >'intuition.i', which is very large and includes about 50 other files, but >it still seems to take too long. Is there a shortcut I can use with >equivalence files or something? 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. If you have the memory, put the include dir in "rad:". You can also use a striped *copy* of intuition.i; that is, remove all of the equates and such that aren't being used (i.e, all the equ's that are absolutely, without a doubt, not being used) Also, try removing some of the include files (one at a time) inside of intuition.i and reassemble the program. If the assembler doesn't complain, then you are probably ok. >Why oh why are the definitions in 'exec/types.i' IN ALL UPPER CASE? >(I'm sure there's a good reason). Sounds like the author yanked it out of something else??? >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! > William LeFebvre > Department of Computer Science > Rice University > <phil@Rice.edu> -- Randy Jouett sun!portal!cup.portal.com!nop or ...!killer!rgj
phil@titan.rice.edu (William LeFebvre) (11/27/88)
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 <phil@Rice.edu>