Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!att!chinet!saj
From: saj@chinet.chi.il.us (Stephen Jacobs)
Newsgroups: comp.sys.atari.st
Subject: Re: Line F
Message-ID: <1989Dec3.042522.21365@chinet.chi.il.us>
Date: 3 Dec 89 04:25:22 GMT
References: <1989Nov8.182505.11625@uunet!unhd> <23996@cup.portal.com> <24111@cup.portal.com> <1261@atha.AthabascaU.CA> <5312@sdcc6.ucsd.edu> <1819@atari.UUCP> <4725b108.20b6d@apollo.HP.COM> <1841@atari.UUCP>
Reply-To: saj@chinet.chi.il.us (Stephen Jacobs)
Distribution: na
Organization: Chinet - Chicago Public Access UNIX
Lines: 20

In article <1841@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes:
>rehrauer@apollo.HP.COM (Steve Rehrauer) writes:
>| I know what you mean by "Line F", but what's the "compression" refer to re:
>| ST ROMs?  (Usually I'm only this dense on Mondays & national holidays...)
>
>The line F compression I refer to is a method we used in ST ROM which
>basically replaces common operations with line F instructions.  The
>line F handler is able, by decoding the $Fxxx instruction, to determine
>what operation to perform.  The handler then dispatches the exception
>to the appropriate OS routine.

This brings up the question of what the ROM code does instead.  Have all the
little line F routines been made into subroutines, with more-or-less ordinary
subroutine linkages (I don't know the exact count, but there are A LOT of
line F routines)?  Are the routines invoked by subroutine calls to a 
dispatcher (a la GEMDOS)?  Has the code been brought inline?  

Of COURSE this is just idle curiosity, but if the answer is 'brought inline',
I'll expect a noticeable speedup in STE performance.
                                        Steve J.