From: Antonio Vargas <wind@cocodriloo.com>
To: John Bradford <john@grabjohn.com>
Cc: Timothy Miller <miller@techsource.com>,
Steven Augart <steve@augart.com>,
Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Simple x86 Simulator (was: Re: Flame Linus to a crisp!)
Date: Fri, 25 Apr 2003 13:44:34 +0200 [thread overview]
Message-ID: <20030425114434.GG6009@wind.cocodriloo.com> (raw)
In-Reply-To: <200304251610.h3PGAiri001509@81-2-122-30.bradfords.org.uk>
On Fri, Apr 25, 2003 at 05:10:44PM +0100, John Bradford wrote:
> > > We could not. Consider just the 8 32-bit-wide legacy x86 registers,
> > > excluding the MMX and FPU registers:
> > > (AX, BX, CX, DX, BP, SI, DI, SP). 32 bits x 8 = 2^256 independent
> > > states to look up in the table, each state having 256 bits of
> > > information. 2^264 total bits of information needed. Assume 1 GB
> > > dimms (2^30 * 8 bits each = 2^33 bits of info), with a volume of 10
> > > cm^3 per DIMM (including a tiny amount of space for air circulation.).
> > > Need 34508731733952818937173779311385127262255544860851932776 cubic
> > > kilometers of space.
> > >
> > > Considerably larger than the volume of the earth, although admittedly
> > > smaller than the total volume of the universe.
> > > --Steven Augart
> >
> > If this could be done, someone would have done it already.
>
> It's certainly possible to implement most of the functionality of a
> very simple processor this way, but applying the idea to an X86
> compatible processor was a joke.
>
> What interests me now is whether we could cache the results of certain
> opcode strings in a separate memory area.
>
> Say for example, you have a complicated routine that runs in to
> hundreds of opcodes, which is being applied to large amounts of data,
> word by word. If one calculation doesn't depend on another, you could
> cache the results, and then merely fetch them from the results cache
> when the input data repeats itself.
>
> I.E. the processor dynamically makes it's own look-up tables.
This is called dynamic programming and is done by keeping a cache
for previous results. Take for example a simple fibonacci function:
int fib(n){
return fib(n-2) + fib(n-1);
}
Now hook up a direct-mapped cache:
int cache[65536];
int fib(n){
int x = cache[n];
if(x) return x;
x = fib(n-2) + fib(n-1);
cache[n] = x;
return x;
}
Of course, this limits the range too much, so coding a LRU or
some other cache system would consume less memory and give
better speed.
Your idea, applying this to general hardware execution could
be _really_ nice in fact :)
Greets, Antonio.
ps. I recall that todays hardware does it for some stuff:
the TBL cache replaces an expensive and sometimes
complex page-table-tree walk (m68030 mmu-docs come
to mind)
next prev parent reply other threads:[~2003-04-25 20:28 UTC|newest]
Thread overview: 204+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-24 3:59 Flame Linus to a crisp! Linus Torvalds
2003-04-24 4:40 ` Joel Jaeggli
2003-04-24 4:43 ` Greg KH
2003-04-24 4:57 ` Linus Torvalds
2003-04-24 5:02 ` Clemens Schwaighofer
2003-04-24 5:39 ` viro
2003-04-24 5:56 ` Valdis.Kletnieks
2003-04-24 8:46 ` Dax Kelson
2003-04-24 9:46 ` Clemens Schwaighofer
2003-04-24 10:54 ` Felipe Alfaro Solana
2003-04-25 0:07 ` Clemens Schwaighofer
2003-04-24 4:54 ` Andre Hedrick
2003-04-24 5:16 ` Linus Torvalds
2003-04-24 13:08 ` Shawn
2003-04-24 20:12 ` Kenneth Johansson
2003-04-24 17:32 ` Andreas Boman
2003-04-24 17:41 ` William Lee Irwin III
2003-04-24 19:39 ` Balram Adlakha
2003-04-26 17:05 ` Riley Williams
2003-04-24 5:02 ` Mark J Roberts
2003-04-24 5:13 ` Clemens Schwaighofer
2003-04-24 5:15 ` William Lee Irwin III
2003-04-24 5:43 ` Linus Torvalds
2003-04-24 6:15 ` William Lee Irwin III
2003-04-24 7:44 ` Jamie Lokier
2003-04-24 8:03 ` Jan-Benedict Glaw
2003-04-25 1:16 ` Jan Harkes
2003-04-25 1:35 ` Stan Bubrouski
2003-04-24 8:16 ` John Bradford
2003-04-24 8:31 ` Jamie Lokier
2003-04-24 8:59 ` John Bradford
2003-04-24 8:50 ` Jamie Lokier
2003-04-24 14:45 ` Linus Torvalds
2003-04-24 15:00 ` Jeff Garzik
2003-04-24 19:03 ` Daniel Phillips
2003-04-24 19:32 ` Timothy Miller
2003-04-24 19:22 ` Linus Torvalds
2003-04-24 20:19 ` Jamie Lokier
2003-04-24 20:35 ` Timothy Miller
2003-04-24 19:39 ` Balram Adlakha
2003-04-24 21:02 ` Jamie Lokier
2003-04-24 18:58 ` Daniel Phillips
2003-04-24 21:08 ` Jamie Lokier
2003-04-24 21:37 ` Timothy Miller
2003-04-24 21:30 ` Jamie Lokier
2003-04-24 21:38 ` John Bradford
2003-04-25 3:20 ` Shawn
2003-04-25 5:47 ` Jamie Lokier
2003-04-25 7:02 ` John Bradford
2003-04-25 8:05 ` Simple x86 Simulator (was: Re: Flame Linus to a crisp!) Steven Augart
2003-04-25 15:38 ` Timothy Miller
2003-04-25 16:10 ` John Bradford
2003-04-25 11:44 ` Antonio Vargas [this message]
2003-04-25 8:52 ` Flame Linus to a crisp! Helge Hafting
2003-04-25 14:03 ` Mike Dresser
2003-04-24 21:42 ` Russell King
2003-04-25 6:08 ` Jan-Benedict Glaw
2003-04-25 11:46 ` Antonio Vargas
2003-04-24 10:57 ` Giuliano Pochini
2003-04-24 22:51 ` Adrian Bunk
2003-04-24 7:55 ` Jamie Lokier
2003-04-24 8:37 ` Andreas Jellinghaus
2003-04-24 8:59 ` Jamie Lokier
2003-04-24 12:52 ` Andreas Jellinghaus
2003-04-24 15:37 ` Timothy Miller
2003-04-24 18:35 ` Alan Cox
2003-04-24 20:46 ` Timothy Miller
2003-04-24 20:50 ` Jamie Lokier
2003-04-24 21:03 ` Chris Adams
2003-04-24 22:29 ` Werner Almesberger
2003-04-24 22:41 ` Jamie Lokier
2003-04-24 22:54 ` Werner Almesberger
2003-04-25 0:26 ` Jamie Lokier
2003-04-24 22:41 ` Alan Cox
2003-04-27 14:21 ` Matthias Andree
2003-04-27 16:13 ` Stephan von Krawczynski
2003-04-27 16:59 ` Why DRM exists [was Re: Flame Linus to a crisp!] Larry McVoy
2003-04-27 17:04 ` Ben Collins
2003-04-27 17:34 ` Michael Buesch
2003-04-27 18:41 ` Henrik Persson
2003-04-27 17:35 ` Måns Rullgård
2003-04-27 17:49 ` Mirar
2003-04-27 23:15 ` H. Peter Anvin
2003-04-27 17:59 ` Michael Buesch
2003-04-27 21:28 ` Alan Cox
2003-04-28 1:48 ` rmoser
2003-04-28 9:05 ` Måns Rullgård
2003-04-28 10:44 ` The X-Window System John Bradford
2003-04-28 14:37 ` Herman Oosthuysen
2003-04-28 16:28 ` uaca
2003-05-06 3:55 ` Miles Bader
2003-04-27 18:07 ` Why DRM exists [was Re: Flame Linus to a crisp!] Matthias Schniedermeyer
2003-04-27 18:35 ` Chris Adams
2003-04-27 18:50 ` Larry McVoy
2003-04-27 19:11 ` Davide Libenzi
2003-04-27 20:13 ` Frank van Maarseveen
2003-04-27 20:34 ` walt
2003-04-27 21:26 ` Alan Cox
2003-04-27 22:07 ` Ross Vandegrift
2003-04-27 22:32 ` Larry McVoy
2003-04-27 22:05 ` Alan Cox
2003-04-27 23:28 ` Larry McVoy
2003-04-28 0:06 ` Ross Vandegrift
2003-04-28 11:03 ` Alan Cox
2003-04-29 18:06 ` Timothy Miller
2003-04-28 9:06 ` Eric W. Biederman
2003-04-28 14:55 ` Michael Buesch
2003-04-28 20:04 ` Matthias Schniedermeyer
2003-04-28 20:18 ` Larry McVoy
2003-04-28 20:22 ` Chris Adams
2003-04-28 21:24 ` Larry McVoy
2003-04-28 21:40 ` Roman Zippel
2003-04-28 22:13 ` Alan Cox
2003-04-28 22:16 ` Alan Cox
2003-04-29 0:09 ` Larry McVoy
2003-04-29 4:07 ` Dax Kelson
2003-04-29 5:08 ` Larry McVoy
2003-04-29 16:40 ` Scott Robert Ladd
2003-04-29 21:45 ` Helge Hafting
2003-04-30 9:58 ` Jamie Lokier
2003-04-30 15:06 ` Scott Robert Ladd
2003-04-29 5:59 ` Theodore Ts'o
2003-04-29 16:41 ` Scott Robert Ladd
2003-04-29 14:35 ` Alan Cox
2003-04-27 22:34 ` Matthias Andree
2003-04-27 22:51 ` Matthew Kirkwood
2003-04-27 23:53 ` Larry McVoy
2003-04-28 0:00 ` rmoser
[not found] ` <20030428001001.GP23068@work.bitmover.com>
2003-04-28 0:19 ` rmoser
2003-04-28 0:37 ` Larry McVoy
2003-04-28 0:40 ` rmoser
2003-04-28 11:38 ` Jan-Benedict Glaw
2003-04-29 14:21 ` Timothy Miller
2003-04-29 14:27 ` Henrik Persson
2003-04-29 19:56 ` Timothy Miller
2003-04-29 20:35 ` Henrik Persson
2003-04-30 8:39 ` Jamie Lokier
2003-04-27 18:47 ` William Lee Irwin III
2003-04-27 18:56 ` Werner Almesberger
2003-04-27 19:20 ` Geert Uytterhoeven
2003-04-27 21:30 ` Jon Portnoy
2003-04-27 21:32 ` Alan Cox
2003-04-27 22:36 ` Larry McVoy
2003-04-27 21:56 ` Alan Cox
2003-04-27 23:08 ` Matthew Kirkwood
2003-04-27 22:16 ` Alan Cox
2003-04-27 23:35 ` Matthias Andree
2003-04-27 22:07 ` Matthias Andree
2003-04-28 0:36 ` Scott Robert Ladd
2003-04-28 9:57 ` Stephan von Krawczynski
2003-05-06 15:58 ` Henning P. Schmiedehausen
2003-05-07 14:44 ` Stephan von Krawczynski
2003-05-07 14:28 ` Alan Cox
2003-05-07 21:40 ` Henning P. Schmiedehausen
2003-05-07 22:16 ` Alan Cox
2003-05-08 0:33 ` Kurt Wall
2003-04-28 11:26 ` Jan-Benedict Glaw
2003-05-06 15:59 ` Henning P. Schmiedehausen
2003-04-28 22:50 ` Timothy Miller
2003-04-29 14:46 ` Jeffrey Souza
2003-04-29 15:16 ` venom
2003-04-30 9:35 ` Jamie Lokier
[not found] ` <20030427171007$6d24@gated-at.bofh.it>
2003-04-27 20:08 ` Why DRM exists Florian Weimer
2003-04-24 19:23 ` Flame Linus to a crisp! Jamie Lokier
2003-04-24 19:50 ` Balram Adlakha
2003-04-24 8:57 ` Arjan van de Ven
2003-04-24 9:19 ` Russell King
2003-04-24 11:38 ` Shachar Shemesh
2003-04-24 17:46 ` Shachar Shemesh
2003-04-24 14:59 ` Linus Torvalds
2003-04-24 12:39 ` Mark Mielke
2003-04-24 15:53 ` Elladan
2003-04-24 18:31 ` Daniel Phillips
2003-04-24 23:15 ` Werner Almesberger
2003-04-25 11:28 ` Eric W. Biederman
2003-04-27 1:31 ` Werner Almesberger
2003-04-27 1:59 ` David Wagner
2003-04-25 14:37 ` Daniel Phillips
2003-04-25 15:17 ` Valdis.Kletnieks
2003-04-25 17:37 ` Werner Almesberger
2003-04-26 21:59 ` Daniel Phillips
2003-04-26 13:00 ` Geert Uytterhoeven
2003-04-26 18:22 ` Linus Torvalds
2003-04-26 18:41 ` viro
2003-04-26 18:48 ` Linus Torvalds
2003-04-28 14:20 ` John Stoffel
2003-04-26 19:23 ` Michael Buesch
2003-04-28 10:35 ` Andre Hedrick
2003-04-28 12:12 ` Jörn Engel
2003-04-28 14:01 ` Zack Gilburd
2003-04-28 14:30 ` Geert Uytterhoeven
2003-04-26 18:21 ` Rik van Riel
2003-04-26 23:34 ` Jamie Lokier
2003-04-27 3:59 ` Werner Almesberger
2003-04-24 20:16 ` Nils Holland
2003-04-25 4:46 ` My take on Trusted Computing and DRM Joseph Pingenot
[not found] <Pine.LNX.4.44.0304232012400.19176-100000@home.transmeta.co m>
2003-04-27 10:52 ` Houston, I think we have a problem Mike Galbraith
2003-04-27 14:41 ` Martin J. Bligh
2003-04-27 17:25 ` Mike Galbraith
2003-04-27 17:29 ` Martin J. Bligh
2003-04-27 17:41 ` Mike Galbraith
2003-04-27 17:54 ` Mike Galbraith
2003-04-28 5:17 ` Mike Galbraith
2003-04-28 6:15 ` Jan Harkes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030425114434.GG6009@wind.cocodriloo.com \
--to=wind@cocodriloo.com \
--cc=john@grabjohn.com \
--cc=linux-kernel@vger.kernel.org \
--cc=miller@techsource.com \
--cc=steve@augart.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).