>From ChangeLog:

  - "Kevin P. Lawton" <[EMAIL PROTECTED]>: Fri Jan 19 12:11:14 EST 2001
    More enhancements to dt-testbed/proto2, and more notes in the README.

>From dt-testbed/proto2/README:

======================================================================
Fri Jan 19 11:46:43 EST 2001

Oops, after adding a little instrumentation, I realized I had
a bug.  Fixed that and reran to get a new set of the numbers,
than the ones I posted.  New results follow; they're close
to the ones before.


                                              (DT/native)
                                           2nd effort  1st effort
  workload      microloops  native    DT   factor      factor
  ----------------------------------------------------------------
  NOP                         .52    6.39   12.3       18.6
  add cascade     5          1.87    7.55    4.0        5.9
  add cascade    10          3.59    9.43    2.6        3.6
  add cascade   100         27.24   33.07    1.2        1.3

These numbers show a little better performance for dynamic branches.
It took only about 5 loops through the add cascade to average out
the slow-down factor to a similar level as 10 loops in the previous
table.

I suppose some more gain could be had from inlining at least
the first hash table entry lookup/compare in the generated
code, rather than do it all in the handler, but that means
more code bloat.  So, good enough for now.  With some real
instrumentation data gathered running real code in the future, it
should be more evident what the code cache size constraints are.  And
how increasing the generated code footprint affects the native CPU
caches.

That's about all of the non 1:1 instructions I'm interested
in working on.  There's some others we can translate rather
than trap on, like selector reads (setting the RPL bits as
expected), eflags reads and such, but they're not that incredibly
interesting or complex to handle.  Branches are the main concern.

Onward to hash out some other architectural details.  I'll manage
a small TODO list.  When that list is depleted, it'll be time to
hammer this stuff into plex86.

-Kevin

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Kevin Lawton                        [EMAIL PROTECTED]
MandrakeSoft, Inc.                  Plex86 developer
http://www.linux-mandrake.com/      http://www.plex86.org/

Reply via email to