A82: Re: ROM_CALLS
[Prev][Next][Index][Thread]
A82: Re: ROM_CALLS
>The way I understand ROM_CALLS are this: When you do a ROM_CALL, it
>calls an address inside Ash which looks up the name of the function you
>wanted, and finds out where it is in your specific ROM version. To put a
Whne you do a rom call, Ash adds an offset to the adresse you are calling
the offset used depends o the rom version. This is the smallest and fastest
way to do the rom calls with the rom versions supported by Ash.
>ROM_call in a program takes up a bit of space, so it is often smaller to
>do this
>
>Disp:
>ROM_CALL(D_ZT_STR)
>ret
>
>than to do 5 rom calls. What if this were in Ash? Most ROM_CALLs are
Using a rom call takes up 5 bytes (CALL ASH_ROMCALL_RUTINE \ .DW
ADRESSE_TO_CALL). The statement above would make you program smaller, but
every function call would taake a bit longer (not important when you are
using text, but it might besometimes).
>slow (DISP_GRAPH, FIND_PIXEL) or are only used when speed is hard to get
>too slow (Printing a text string), so how about this: At a certain
>address inside the Ash code is the following code:
>
>ROM_CALL(D_ZT_STR)
>ret
>
>Now, we could do a call $ASH_ADDR+$dztrstroffset and that would make
>every ROM CALL a couple bytes smaller. This would impact speed, as it is
>another layer of calls.
>
>Another way to do it would be this:
>
>call D_ZT_STR ; D_ZT_STR is an address inside of ash which does the
>following:
>
>If ROMVERS = 18 then call $ROM18DZTSTR
>If ROMVERS=19 then call $rom18dztsr
>ret
>
>Not sure about the advantages of this latter one, as I have not seen the
>code in ash taking care of Rom calls. So, Dines, how about implementing
>the former idea in your new shell?
The way rom calls are handled in Ash is a lot smaller than your idea, but
the new shell will hopefully support more romversions than Ash, and this
gives us some problem. Some of the early versions of the rom does not
contain all the calls the others do which makes it impossible to use the
method Ash uses. There for we have to use a method like the one OS82 is
using know, and unfortunatly that is a lot slower than the one used in asm.
The new method for handling rom calls means that the shell needs a table of
addrs for each rom versions. It is however possible to make the tables in a
way which means that you do not have to use rom_calls. So in your program
you would just call and adr in Ash. This would mean even faster romcalls
than Ash haves. The problem with this method is that it takes 44 bytes more
(according to the creators of usgard who alss used this method).
I do think it is a good idea to implement this type of rom calls in the new
shell, but we will see what happens.
Dines