Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[SamuraiCrow]

It works here.

One comment of something to watch for when renaming libraries:  AmigaDOS is case-insensitive but Exec.library's OpenLibrary command might not be.  Be sure to rename AMOS.Library appropriately, not amos.library.  (If it works though, post here so I will update my knowledge.  I'm just going on the word of another programmer and haven't tried it out myself.)

Edit:
Confirmed as a bug in OpenLibrary Autodocs.  See here.

Ah, but amos.library is not an AmigaDOS library (so maybe it shouldn't be in LIBS: in the first place  ).  It's a custom collection of three sets of library routines.  So AMOSPro uses LoadSeg() to get it into memory.   It expects to find it in one of three locations, which it tries in this sequence:

• APSystem/amos.library
• libs/amos.library
• libs:amos.library

These names are what are used in the +B.s source and are what you'll see in the resulting AMOSPro binary (i.e.  all lower-case).

Once in memory, it has a jump and data list in the first six longwords.  To cut a long story a bit shorter, the "startup" jump expects to find A5 pointing to an initialised AMOS data area.  It uses that to initialise the following vectors in the first three negative longword offsets from A5:

• SyVect - offset -4, points to the "system" jump table
• EcVect - offset -8, points to the "screens" jump table
• WiVect - offset -12, points to the "windows" jump table

The macros SyCall, EcCall, WiCall and their variants are used, together with the instruction number equates in +Equ.s, to call the functions.

AMOSPro only uses _LVOOpenLibrary() for:

• dos.library
• intuition.library
• mathffp.library
• graphics.library
• icon.library

which all appear in the sources, as in the above list, in lower-case.

Fascinating!  I suppose if the Double Precision flag is set, it substitutes IEEE double-precision floating point for Motorola fast floating-point soft floats?

[bruceuncle]

I suppose if the Double Precision flag is set, it substitutes IEEE double-precision floating point for Motorola fast floating-point soft floats?

That's more or less what happens.  That's where I got the idea of using a 'context switcher' to cope with different graphics environments.  It involves a bit more than just loading in and opening mathieeedoubbas.library and mathieeedoubtrans.library.  The routines have to be switched too.  Have a look at the "FSwp" table at the end of the tokens table in +Lib.s, and also at the code in +ILib.s from the Open_MathLibraries label onwards.  It involves a bit of swapping back and forth between +Lib.s and +ILib.s to follow the threads.  I haven't been into it in any detail myself yet.
You might also have a look at the attached docs in the CSI AMOS thread here on page 4.  With that document I'm only up to the point where the AMOS libraries have been loaded and initialised.  What you're asking about comes next and will have to be documented fully when I get to the interpreter and individual instruction sets .
I'll be publishing more on CSI AMOS as time goes by.  I tend to flit from one task to the other whenever boredom or obfuscation sets in  .  So some threads may be dormant for a while but they're not forgotten.  I keep putting off finishing the help docs as it's such a big task.  But I think I'd be better off concentrating on that until it's complete.  Especially as it's now a part of the AMOS V2.10 releases.

[SamuraiCrow]

I've been looking at that document and puzzling over the startup code.  Would it be possible in the future to make Amos.library a real shared reentrant library?  That way it should be possible to multitask with Amos programs.  It might need to wait until the AROS 68k version which supports multiple inheritance in its HIDD structure using OOP.library but that might be ok anyway.

[bruceuncle]

I've been looking at that document and puzzling over the startup code.  Would it be possible in the future to make Amos.library a real shared reentrant library?  That way it should be possible to multitask with Amos programs.  It might need to wait until the AROS 68k version which supports multiple inheritance in its HIDD structure using OOP.library but that might be ok anyway.

AMOS Pro can operate in a multi-tasking environment already.  What it can't do is multi-task using multiple AMOS Pro copies.

There are many problems associates with converting it to a more 'friendly' version:

• amos.library is currently very tightly coupled to both the standard and third-party extension libraries.  I don't like that either, but I can live with it as it's at least consistent.
• amos.library could obviously be rewritten to look like an AmigaDOS library with all the routines available as standard library offsets with the associated list of function equates.  One hell of a project but feasible!  However, whilst the current calling macros could easily be replaced in the standard AMOS *.Lib files, we'd be stuffed for any extensions for which we don't have the source.  Which limits it a bit too much.  If going for this option, it would then be better to rewrite amos.library in C and tweak it in assembler.  The reasons are stated below.
• AMOS delegates some hardware timing dependencies to the programmer.  As many have found to their cost if things are not done strictly as per manual!  For example, many instructions setup the hardware registers.  They then expect the user to program a Wait Vbl so's the changes can take effect.  Without that, there's a good chance that the changes will be ignored with, usually, disastrous results.  AMOS doesn't automatically do this at the low level as, if the programmer uses a number of hardware setup instructions one after another, there would be a 1/50th second penalty for each instruction.  Currently they can do that and then issue a single, unavoidable, Wait Vbl incurring only one 1/50th second penalty.  In a multi-threaded environment this would be taken care of at the low level (i.e. it would be in the equivalent of amos.library).
• The Amiga hardware programming requirements would mean:
  
  • Careful partitioning in the code to allow protected routines to be uninterruptible.
  • Checks for race conditions and code to handle them.
  • Checks for deadlocks and code to handle them.

So what would be the point of expending all that effort?

[SamuraiCrow]

In the Mattathias Basic environment, we were going to do exactly that:  Replace all of the Amos compiler with C functions and an independent, new extension format.  Now that we have the Amos source, I was hoping there would be an easier way.  Toward the end of my stint as a compiler designer, I was thinking that converting 68k assembly code to the equivalent LLVM assembly format would be the easiest approach anyway.

Sidewinder thinks the LLVM compiler framework is too heavy for a classic Amiga in its present state.  I was thinking it would be easier to rewrite the LLVM optimizer to make it more modular using shared libraries for each "pass" of the optimizer to allow the OS to flush out the ones that aren't being used at a given moment.  That way we wouldn't require a 2GiB+ computer to do the optimizing and linking of our code.

I guess I'd better give it some more thought.