home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!spool.mu.edu!yale.edu!ira.uka.de!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!corton!loria!loria.crin.fr!eker
- From: eker@loria.crin.fr (Steven Eker)
- Newsgroups: comp.sys.m68k
- Subject: Re: 68000, Fast 14 Bit Shift?
- Message-ID: <569@muller.loria.fr>
- Date: 6 Nov 92 11:10:27 GMT
- References: <memo.723415@cix.compulink.co.uk> <1992Nov4.175727.6305@jato.jpl.nasa.gov>
- Sender: news@news.loria.fr
- Organization: CRIN (CNRS) Nancy - INRIA Lorraine
- Lines: 25
-
- In article <1992Nov4.175727.6305@jato.jpl.nasa.gov>, jdickson@jato.jpl.nasa.gov (Jeff Dickson) writes:
- |> > [a tad more source deleted]
- |> >
- |> >> move.b (a3)+,d0 ; encoded line length (first byte)
- |>
- |> EXT.W D0
- |>
- |> >> move.b table(pc,d0.w),d0 ; decoded line length (can't be -ve!)
- |> >> adda.w d0,a2 ; number of bytes extracted (flags not changed)
- |> >
- |> > Why do you do add.w ? Surely the file could be >65K. i know
- |> > d0 is word size, but you still need all 32 bits ??. e.g if
- |> > a2 has $0000EFFF and you add 2 bytes as a word you'll lose the
- |> > carry.
- |>
- |> Am I being presumptuous here or is it no big deal that D0 is not sign extended
- |> to a word?
-
- Assuming that the table starts at 0 (and that was implicit in the
- original unoptimised code) we are dealing with unsigned chars and
- it is _wrong_ to sign extend because we would end up accessing elements such
- as table[-128] rather than table[128]. The top 3 bytes of d0 are zero'd
- once in the intialization code (deleted) and stay zero'd throughout the routine.
-
- Steven
-