A89: Re: More Help

[Prev][Next][Index][Thread]

A89: Re: More Help


> Hope you guys don't mind a few beginner questions...

Not at all - easier to answer (well, most of the time... =)  ).

> I mostly have questions about nostub-specifics and compiler syntax.
>
> First, what is the overall format of a nostub assembly program

Search the A89/A92/Older mailing lists on ticalc - there are some discussions on
the exact format of the on-calc (and off-calc) files.

> (I've found
> examples of nostub C programs...but any assembly stuff I've found has assumed
> you're writing for a shell)?  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...?
>  Like in
> ZShell you had to add the program's address to the relative address of the
> label to access in-program data, and in Usgard you simply preceded references
> to such addresses by an amperstand so the compiler could create a relocation
> table.  I'm thinking in-program branching (both jumps and calls), from what
> I've gathered, doesn't need any sort of relocation, since those instructions
> are relative anyway...but correct me if I'm wrong on this ;)

Anything within a program can be relative  - the TIOS format does file
relocation for you. You cannot, however, use libraries or similar without
relocating them yourself first (this is basically what a kernel/"shell" does).
So yes, you can jump to / reference a label directly.
This is as long as you don't muck around too much with the memory
allocation/deallocation/other ROM functions - they can move stuff around if
you're not careful - but that's another story.

> 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?

The locations of the actual functions move around, but the ROM has a table of
all of them, and the location of this table is stored at a fixed address. Also,
the indexes in this table for each functions remain constant over AMS versions.
Disclaimer: This is how it is supposed to work, but TI probably won't follow it
until after the SDK has been officially released.

Somone reply to this with the first address I mentioned - from that and the
TI-GCC library / DoorsOS docs you can get all the ROM function addresses.

> 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?

The "xdef":ed ones are exported like you say and are generally used in
libraries.
AFAIK, the "\label" is no different from "label:", but you can use them like I
do: "\label" is a local label, used in a loop or otherwise connected piece of
code, whereas "label:" is something that can be reached or used from anywhere in
the program.

> 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...

a68k should come with some documentation. If not you could always check out the
original a68k on AmiNet or something.

> 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?)?

asm("") supports several directived to decide which register gets loaded with
what input/output variable. It's too late for be to go into details here (and
someone else hopefully will do that anyway) so I'd suggest looking at the gcc
docs. You can browse them at several places on the web, like www.delorie.com
(look in "software" for gcc iirc).

> Sorry if these questions are...well..."obvious", but maybe my ignorance is
> due to my attempt to form parallels between the Z80/TI-85 and the M68K/TI-89
> ;)  If someone would be willing to help me get on my feet directly through
> email/AIM, be my guest ;)

The main difference is that the Z80 is ackumulator-based (all results end up in
a special register, in fact all registers are special) whereas the 68k is more
general - all registers are general (four serve special purposes, but can be
used for everything the others can).



BIG DISCLAIMER:
It's 3 in the morning and I'm tired, m'kay?

--
 / Niklas Brunlid
Check out Prosit for the TI-89 / TI-92+ at http://prosit.ticalc.org
Random PQF v5.1 Quote follows:

Sham Harga had run a succesful eatery for many years by always smiling,
never extending credit, and realizing that most of his customers wanted
meals properly balanced between the four food groups: sugar, starch, grease
and burnt crunchy bits.
        -- (Terry Pratchett, Men at Arms)
References: