🚀 go-pugleaf

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>