A89: More Help
[Prev][Next][Index][Thread]
A89: More Help
> Hope you guys don't mind a few beginner questions...
I don't think you'll get any complaints when asking _reasonable_ questions -
much of what you're asking is either poorly documented or not documented at
all (we really need a good tutorial for people who _don't_ already know ASM,
too). There's a huge difference between people asking questions because
they CAN'T find answers, and people asking because they WON'T find answers.
In response to your earlier inquiry about opcodes, you'll want to order a
few books from Motorola (all free). Head on over to
http://merchant.hibbertco.com/mtrlext/ , click "General Search" on the left
sidebar, and enter "68000" in the DOC # field.
You want to get the top two items that come up:
M68000PM/AD - M68000 FAMILY PROGRAMMER'S REFERENCE MANUAL R1
This manual lists and explains in detail all the instructions and opcodes,
among other things. You'll be able to guage the size of any instruction and
convert from instruction <--> opcode, but it doesn't list the instruction
timings.
M68000UM/AD - M680008 /16 /32 BIT MICRO USERS NINTH EDITION R8
The User's manual has all of the instruction timings. You're interested in
Chapter 8: 16-bit instruction times (not Chapter 7, which is 8-bit).
> First, what is the overall format of a nostub assembly program (I've found
> examples of nostub C programs...but any assembly stuff I've found has
assumed
> you're writing for a shell)?
I believe you just want to xdef _nostub, _main, and _ti89 and/or _ti92plus.
Don't use any RAM Calls or library calls, and use the ROM_CALL macro for ROM
Calls.
> Also, what things should I be concerned with in
> a nostub program (this is a pretty vague question...)? For example, can I
> make references to in-program addresses by their label directly, or must I
> use the x(PC) effective address method, or some other method...?
No difference in the method of addressing at all; ROM Calls are handled
differently (use the ROM_CALL macro instead) and library/RAM Calls aren't
allowed.
> Also, where could I get a list of ROM functions and RAM locations? I
think
> it was at 89 Central that I read that it's probably safe to directly
access
> the ROM function table and RAM addresses, since it would be unlikely for
TI
> to change these in future AMS versions...true? Comments? I checked the
> doorsos include file for assembly files in TI-GCC, and it just equated ROM
> functions to what looks to me like other labels (_ROM_CALL_xxx)...why's
that?
When the linker encounters _ROM_CALL_xxx, it translates that into the code
for the actual call, but since you don't want to be writing _ROM_CALL_xxx,
the english equates are all defined there.
Don't directly address the ROM function table; it's at different locations
in different ROM versions. But a pointer to the start of the table is
always as $C8, so use that to access the table.
A list of the locations? Well, there isn't any main list, that's one of the
problems. doorsos.h and tios.h (they should be IDENTICAL, and I hate seeing
the doorsos name being accredited with TIOS calls) list the common used
equates, and information about SOME of them can be found in the docs folder
of the doors zip.
TIGCC includes many more equates than the assembly header files as well as a
description of their usage in C-style definitions, but it's up to you to get
the calls you need outta there if they're not in the ASM header files. The
whole situation is a mess.
> One thing I noticed while reading on programming for the TI-89/92(+) is
that
> there seems to be three different types of labels used in source codes.
> Those whose (I'm guessing) addresses appear in the header of the compiled
> program (preceded with the compiler directive "xdef" at the top of the
source
> and starting with an underscore [is that underscore necessary?]), the
> "regular" ones that are just like "label:", and those that start with a
> backslash, like "\loop:". Is there a fundatmental difference between
these
> labels, or are the prefixes (or lack thereof) there merely for source
> readability?
xdef makes a label external (just like the extern keyword in C), so if
you're linking together multiple object files, any shared addresses will
need to be xdef'd. In addition, certain symbols are read by the linker, and
those must be xdef'd, too.
"Regular" labels are. . . well, regular labels.
Labels starting with a backslash are considered local labels; they're local
to the last non-local label above them. Two local labels can share the same
name as long as they're local to different parts of the code, so I'll often
use "\loop:" as a label name in several places in my source. If the label
is only accessed from within its own routine, I'll make it local; if it has
to be accessible from anywhere in the source, I'll make it normal. Many
people just choose to ignore local labels and create a unique label name for
every routine instead.
> Also, is there some document that explains all the compiler directives and
> syntaxes available with the a68k assembler? Like for TASM there was
> "tasm.doc" that gave all available compiler directives listed
> alphabetically...that thing helped me a lot ;) The "readme.txt" doesn't
seem
> to help much, but maybe I'm just not looking hard enough...
It took me months to find compiler directive listings - there aren't many,
but the conditional ones sure are helpful. You can find a listing at
http://www.technoplaza.net/assembly/index.cgi?p=supplement1 - the
conditional stuff, however, still isn't documented very well.
Here's a quick explanation of using "ifeq" - you define a value by doing
something like this:
[NAME] SET [VALUE]
For example:
BALLSIZE SET 1 ;1 smallest, 2 mid, 3 largest
Then test if it's equal to some value by subtracting that value:
ifeq BALLSIZE-1
since ifeq is true if the value is zero, then code here will only be
executed if BALLSIZE is set to 1. Endif is done by a simple:
endif
Note that if you're testing a value with compiler directives, "SET" the name
to the value. If you're using it as a constant in the code, you "EQU" the
name to the value, as in:
TURNRADIUS EQU 3 ;higher = smaller
add.w #TURNRADIUS,d2
Yes, it's a very bad system. I should release my d360 source for
educational purposes; it's been sitting on my hard drive for a year. I'll
comment it one day =)
> Oh, one more question (for now). I'm not really familiar with mixing
> high-level languages with assembly language; all I really know is that the
> <asm(" ")> function (?) allows one to include assembly instructions in C
> source code. But how would one go about communicating information between
> the C code and the assembly code? I'm guessing the route to go would be
the
> stack...such as with functions...but how would you write an assembly
function
> that C code could utilize (format/syntax?)?
I'll back off for Zeljko and Niklas to explain that here - GCC's asm()
function makes communicating between C and ASM code very, very easy and
effective - you just tell it what value each register has at the start (that
can be a C variable), what each one has at the end, and what registers are
destroyed in the process. The synatax, however, I find to be very
confusing, and both Zeljko and Niklas (and even good old Zoltan) had to do a
lot of explaining before I figured it out
-Scott
Follow-Ups:
References: