Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!erd
From: erd@tut.cis.ohio-state.edu (Ethan R. Dicks)
Newsgroups: comp.sys.amiga
Subject: Problem with -b vs -b0 option on Lattice
Keywords: Lattice V4.01 V5.00 GURU
Message-ID: <29526@tut.cis.ohio-state.edu>
Date: 14 Dec 88 06:33:45 GMT
Distribution: na
Organization: The Ohio State University Dept of Computer and Information Science
Lines: 42

In my OnePlane program, I have to compile it with the -b0 option, to turn
off base A4 referencing, because it GURU's with a 0000003.addr if I just
run it, and a 0000004.addr if I examine it with the MetaScope debugger.

The line it chokes on is...

struct ExecBase *ExecBase, **EBase;

EBase = (struct ExecBase **) (4L);
ExecBase = *Ebase;

If I compile the code with the -b0 option, the code works perfectly, and
I get the contents of the address 0x0000004 loaded into A6.  If I compile
the code with the -b option, I never get up to the library open, immediately
following this code.

Under assembly, as I recall the proceedure is to simply do a

	LEA	$4, A0
	MOVE	(A0), A6

However, in C, this is not so easy.  The reason for this convolution is that
my program links with *nothing*; no startup code, no libraries.  I need to
generate the ExecBase pointer entirely in my own routine.  The reason I am
wanting to use the -b option (the default) is that the code size changes from
440 to 300.  I want to take advantage of this 30% reduction in executable
size.

So... enough background ...

What is the best way to aquire the ExecBase pointer manually?  I got my
technique from the WhatCPU program by Dave Haynie.

Why would base relative addressing cause code to begin GURUing with odd
offsets?

Thanks,
-ethan
-- 
Ethan R. Dicks       | ######  This signifies that the poster is a member in
Software Results Corp|   ##    good sitting of Inertia House: Bodies at rest.
2887 Silver Drive    |   ##
Columbus OH    43211 | ######  "You get it, you're closer.