Re: 68K/68332 Assembly/Binary Problem

On Mar 31, 2:15 am, Robert Redelmeier <red...@xxxxxxxxxxxxxxx> wrote:
kevi...@xxxxxxxxx wrote in part:

I just coded a LUT generation subroutine and it took <10000
cycles up to 10^20; I guess that bodes well enough for the
conversion algorithms if I can get them done and working.

500 clk/decimal digit isn't very fast. DIV may be faster!
I'd expect a LUT to be <50, possibly <20.

-- Robert

Well that's just the initial generation subroutine;

Currently I have a full 64-bit integer read from the Terminal;
converted into binary and then converted back into a String and
printed in 24k cycles. That's including the LUT generation which only
happens once per program initialisation. Ignoring the initial table
generation and the I/O it's about 10k for all the conversions.

In what sort of implementation do you think DIV would be faster?

.

Relevant Pages

  • Re: Xen & VMI?
    ... Rather than perform a conversion from cycles to ... nanoseconds is neither an arbitrary time unit nor will it change anytime ... time for your clock event reprogramming. ...
    (Linux-Kernel)
  • Re: Xen & VMI?
    ... quite bad unit for an API, it should be absolute time, nanosec or picosec based instead. ... We could easily see CPUs that have /no concept of ... Rather than perform a conversion from cycles to nano/femto/pico seconds, the raw cycle count is exposed, along with the current clock frequency. ... This allows the timer infrastructure to merely do one conversion, from cycles to real time, rather than converting to an arbitrary time unit which may change with operating systems and time and thus break the ABI. ...
    (Linux-Kernel)
  • Re: Finding the highest bit set in a 32-bit number
    ... > adding that to an unsigned int. ... That conversion takes a few cycles. ... > So it might be faster to either make the table uint, ...
    (comp.programming)
  • Re: Question on Metastability
    ... I can always pipeline the conversion - I do have a dozen or so cycles to play with before I need to get the result out. ...
    (comp.arch.fpga)