Amiga Memory Map Needed! / ExecBase
IAN J. EINMAN
in the os. No application needs to know about interrupts, I think.
So it's allright if internally the os uses absolute addresses, but
there is no need to make anything external rely on them. Or even
know about them.
ExecBase being absolute: It has to be! The application MUST know exactly where Exec
is at. The OpenLibrary function is in Exec, so if Exec was an openable library with
a variable base address, this would be a paradox.
If the ExecBase was obtained in a different way, how? If it moved around, how could
you find it? It is virtually impossible to not have at least one absolute address in
a system. The only way to circumvent it would be to pass the ExecBase pointer in a
register to the program when it first starts... but that wouldn't be too platform
independent either.
There is NO way to run a program that accesses any OS function without relying on
either: fixed addresses, fixed register(s), or fixed interrupts. (like the Mac;
0xA000 line interrupts call system functions.)
Philipp Boerker
>ExecBase being absolute: It has to be!
No.
[...]
>There is NO way to run a program that accesses any OS function without relying on
>fixed addresses
Yes there is. A pointer to ExecBase could be passed to the task in a6 when the task
is started.
Greets,
Phil.
grond/matrix
Dennis Lee Bieber
In article <4facl8$g...@brachio.zrz.TU-Berlin.DE> rawn...@w353zrz.zrz.TU-Berlin.DE (Philipp Boerker) writes:
> Yes there is. A pointer to ExecBase could be passed to the task in a6 when the task
> is started.
>
ExecBase?
--
> ============================================================ <
> wulf...@netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
> D.Bi...@GEnie.com | FurryMUCK and FurToonia <
> ============================================================ <
> PGP key: Finger wulf...@netcom.com <
> Home Page: ftp://ftp.netcom.com/pub/wu/wulfraed/wulfraed.htm <
Michael van Elst
>It will have it from an fixed address of course, but this address could
>vary from computer to computer, from OS version to OS version. No user code
>should rely on fixed addresses or other hardware. Supervisor code has to.
>UNIX shows how to do it.
Rubbish. UNIX uses trap instructions to call system routines. If every
library function would use a trap this would be abysmally slow. That's
why shared libraries in UNIX use a different method. Most even use fixed
addresses for library entry points.
The only method that avoids any absolute address would be to pass a pointer
to every new task, which wouldn't be consistent (interrupts still have to
fetch ExecBase from a fixed address) and requires extra magic (because the
first task has to magically "know" the pointer). And all this just for
aesthetics with not a single advantage in functionality.
--
Michael van Elst
Internet: mle...@serpens.rhein.de
"A potential Snark may lurk in every tree."
Philipp Boerker
> > Yes there is. A pointer to ExecBase could be passed to the task in a6 when the task
> > is started.
> >
> And how did the code that starts /that/ task obtain the pointer to
>ExecBase?
It will have it from an fixed address of course, but this address could
vary from computer to computer, from OS version to OS version. No user code
should rely on fixed addresses or other hardware. Supervisor code has to.
UNIX shows how to do it.
Regards,
Phil.
grond/matrix
Philipp Boerker
>>It will have it from an fixed address of course, but this address could
>>vary from computer to computer, from OS version to OS version. No user code
>>should rely on fixed addresses or other hardware. Supervisor code has to.
[rude corrections cut here ;) ]
>The only method that avoids any absolute address would be to pass a pointer
>to every new task, which wouldn't be consistent (interrupts still have to
>fetch ExecBase from a fixed address) and requires extra magic (because the
>first task has to magically "know" the pointer).
This fixed address could be a constant that differs from compilation to
compilation of the OS.
> And all this just for aesthetics with not a single advantage in
> functionality.
It wouldn't be to much effort to pass ExecBase at the beginning. The user
code would have to store it (move.l a6,ExecBase) and go on reading it from
there (move.l ExecBase,a6). Where is the problem?
Regards,
Phil.
Philipp Boerker
>>>ExecBase being absolute: It has to be!
>>No.
>>[...]
>>>There is NO way to run a program that accesses any OS function without
>>>relying on fixed addresses
>>Yes there is. A pointer to ExecBase could be passed to the task in a6 when
>>the task is started.
>Maybe you should read Ian's whole message. I don't think
>different processors have the same registers as the 680x0.
Hm, a stack pointer is defined for all processors I know...
(And passing arguments with the stack is common too)
> And thatswhy
>an absolute memory-address is better.
Of course it is better. I made the point that it is *possible* to
not have a fixed address for user code.
Greets,
Phil.
Villellas Guillen Oscar
> In article <4facl8$g...@brachio.zrz.TU-Berlin.DE> rawn...@w353zrz.zrz.TU-Berlin.DE (Philipp Boerker) writes:
> > Yes there is. A pointer to ExecBase could be passed to the task in a6 when the task
> > is started.
> >
> And how did the code that starts /that/ task obtain the pointer to
> ExecBase?
a) because it got it when it was first started.
b) because is the task that starts the machine. It has to
load execand will know where exec is. If exec is in ROM, and
the startupcode is in the same ROM, then it can be hardcoded
for that case.
I think execbase does nt need to be absolute, and somewhere
in the stack at the task statup is OK for it to be passed to
child tasks (better protability than a register).
> --
> > ============================================================ <
> > wulf...@netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
> > D.Bi...@GEnie.com | FurryMUCK and FurToonia <
> > ============================================================ <
> > PGP key: Finger wulf...@netcom.com <
> > Home Page: ftp://ftp.netcom.com/pub/wu/wulfraed/wulfraed.htm <
--
//\\\
/o \\
+-----oooO--(_)--Oooo-----+ _ _
| Oscar Villellas Guillen | ////
+-------------------------+ _ _ ////
| | | \\\X///
ooO Ooo \XXX/ Always...
ii...@rossegat.uji.es Intuition rules!
Michael van Elst
>This fixed address could be a constant that differs from compilation to
>compilation of the OS.
No.
>It wouldn't be to much effort to pass ExecBase at the beginning. The user
>code would have to store it (move.l a6,ExecBase) and go on reading it from
>there (move.l ExecBase,a6). Where is the problem?
Where is the problem in move.l AbsExecBase.w,a6 ?
Michael Berg
MvE> Where is the problem in move.l AbsExecBase.w,a6 ?
Well if you do it a lot it's kind of slow on accellerated machines.
__
__/// Michael Berg
\\X/ mb...@datashopper.dk
.. Experience varies directly with the equipment ruined.
Michael van Elst
> MvE> Where is the problem in move.l AbsExecBase.w,a6 ?
>Well if you do it a lot it's kind of slow on accellerated machines.
Sure. But that's only done once per program.
Magnus Holmgren
IJE> ExecBase being absolute: It has to be! The application MUST know
IJE> exactly where Exec is at. The OpenLibrary function is in Exec, so
IJE> if Exec was an openable library with a variable base address, this
IJE> would be a paradox.
Would it? The system startup code should be able to handle this, IMHO, even
without a fixed address..
IJE> If the ExecBase was obtained in a different way, how? If it moved
IJE> around, how could you find it? It is virtually impossible to not
IJE> have at least one absolute address in a system. The only way to
IJE> circumvent it would be to pass the ExecBase pointer in a register
IJE> to the program when it first starts... but that wouldn't be too
IJE> platform independent either.
But what startup code is platform independent? You need some dependent
parts, and startup falls into this category.
Besides, fixed register or fixed memory location, what difference is there?
Same dependancy, only a different way to find the information. And here I
must say I'd prefer a fixed register (mostly because the address 4 on the
Amiga isn't in the fastest address range).
Side note: I'e written a library (that makes rather heavy use of system
resources), that _never_ references address 4. There is no need to do it.
For (most) programs, one access should be enough.
IJE> There is NO way to run a program that accesses any OS function without
IJE> relying on either: fixed addresses, fixed register(s), or fixed
IJE> interrupts. (like the Mac; 0xA000 line interrupts call system
IJE> functions.)
True (but the Mac (and some old CP/M implementations) isn't one I like. I
mean, there is a certain amount of overhead in exception processing ;).
--
Magnus Holmgren - Amiga programmer and enthusiast
Timothy Eves
The Amiga has what is called a Soft Architecture which means that it has
no absolute memory map. The ONLY absoulute address that any one can be
sure of with the OS memory map is memory address $00000004 *points* to
ExecBase. All other OS structures and resources have pointers to them
stored in the ExecBase struct. Now on machines equiped with fast ram I
belive the OS moves the ExecBase structure into fast ram.
:must say I'd prefer a fixed register (mostly because the address 4 on
the
:Amiga isn't in the fastest address range).
That doesn't matter. As long as you copy the pointer to exec base to a
pointer in fast mem then you will get the fastest indrect jsr's you can.
:Side note: I'e written a library (that makes rather heavy use of system
:resources), that _never_ references address 4. There is no need to do
it.
Never? It must reference it at least once to copy the value stored
there, if you're calling OS routines.
:For (most) programs, one access should be enough.
True
Tim Eves
------------------------------------------------------------O----------------
Out of the gloom came a voice, "Smile and be happy things| EMail To:
could be worse", it said. So I smiled and I was happy,|
se...@dmu.ac.uk
and behold things did get worse. |
------------------------------------------------------------O----------------
ch...@wiloyee.shnet.org
: rawn...@w351zrz.zrz.TU-Berlin.DE (Philipp Boerker) writes:
:
: >This fixed address could be a constant that differs from compilation to
: >compilation of the OS.
:
: No.
:
: >It wouldn't be to much effort to pass ExecBase at the beginning. The user
: >code would have to store it (move.l a6,ExecBase) and go on reading it from
: >there (move.l ExecBase,a6). Where is the problem?
: Where is the problem in move.l AbsExecBase.w,a6 ?
There is one problem: porting amiga os to another plattform. i often though
about how this could be done, although i don't really wanted to start such a
project. but some hardware does not allow addres $4 to be modified, like the
atari st hardware. of course, you could remap with mmu, but everything would
be so simple if there would not be this one absolute adress. kilobytes of
absolute data starting from $400 would be no problem for most mc68000
systems, but please not one of the few adresses in the first kilobyte that
really makes sence to be implemented as rom.
well, it really doesn't matter at all.
Frank Wille
about "Re: Amiga Memory Map Needed! / ExecBase" :
MvE> rawn...@w351zrz.zrz.TU-Berlin.DE (Philipp Boerker) writes:
MvE>
MvE> >It wouldn't be to much effort to pass ExecBase at the beginning. The
MvE> >user code would have to store it (move.l a6,ExecBase) and go on
MvE> >reading it from there (move.l ExecBase,a6). Where is the problem?
MvE>
MvE> Where is the problem in move.l AbsExecBase.w,a6 ?
I see two problems with AbsExecBase. It's in Chip-Ram, and accesses
will be much slower as if it was stored in a variable in 32-bit
Fast-Ram. You will get an additional slowdown, when running a pro-
gram like Enforcer at the same time, which has to emulate all
accesses on $4.
-- _
_ // Frank EMail: fr...@phoenix.owl.de
\X/ IRC: Phx @ #amiga(ger)
Sebastian Rittau
>Besides, fixed register or fixed memory location, what difference is there?
>Same dependancy, only a different way to find the information. And here I
>must say I'd prefer a fixed register (mostly because the address 4 on the
>Amiga isn't in the fastest address range).
The difference is that other processors can have a different structure.
The registers are not d0-d7 and a0-a7. Maybe they have no specialized
registers or only specialized registers. But memory is something every
computer must have. And therefore nearly every computer has a
memory-address of 4.
>Side note: I'e written a library (that makes rather heavy use of system
>resources), that _never_ references address 4. There is no need to do it.
>For (most) programs, one access should be enough.
That's the normal way, isn't it? You get the address once and store it
somewhere. In libraries this isn't needed, because you get the execbase
in the init-routine from the system.
--
// Sebastian Rittau jro...@jroger.in-berlin.de
\X/ http://www.in-berlin.de/User/jroger/index.html
Michael van Elst
>I see two problems with AbsExecBase. It's in Chip-Ram,
It is _now_ in Chip-RAM.
>and accesses
>will be much slower as if it was stored in a variable in 32-bit
>Fast-Ram.
Sure. That's why you want to copy it to a private variable. But this
is pretty much independent on wether the pointer is kept in memory
or passed in a register.
>You will get an additional slowdown, when running a pro-
>gram like Enforcer at the same time, which has to emulate all
>accesses on $4.
You always get this kind of slowdown when you access a protected data
structure.
Børge Nøst
>|> It is _now_ in Chip-RAM.
Been there, done that. Works.
If you want an executeable for 040/060 that does it you can get it from me.