Age | Commit message (Collapse) | Author |
|
--HG--
extra : convert_revision : 8cc2943ebc41e4d430789ee7923dd0dc878be06b
|
|
into zazzer.eecs.umich.edu:/z/rdreslin/m5bk/head
--HG--
extra : convert_revision : 11df5fb2a8f1fa020d042e75b22a7f2f2bcbd9ab
|
|
into zamp.eecs.umich.edu:/z/ktlim2/clean/tmp/head
--HG--
extra : convert_revision : 05f738ab6cf1e8bd2940f4ce20602f1e8ad1af48
|
|
src/cpu/o3/cpu.cc:
Use proper cycles for these equations.
--HG--
extra : convert_revision : cd49410eed978c789d788e80462abed6cb89fbae
|
|
--HG--
extra : convert_revision : c82a62a61650e3700d237da917c453e5a9676320
|
|
not a cpp file because c99
(which defines fenv) doesn't necessarily extend to c++ and it is a problem with solaris. If really
desired this could wrap the ieeefp interface found in bsd* as well, but I see no need at the moment.
src/arch/alpha/isa/fp.isa:
src/arch/sparc/isa/formats/basic.isa:
use m5_fesetround()/m5_fegetround() istead of fenv interface directly
src/arch/sparc/isa/includes.isa:
use base/fenv instead of fenv directly
src/base/SConscript:
add fenv to sconscript
src/base/fenv.hh:
src/base/random.cc:
m5 implementation to standerdize fenv across platforms.
--HG--
extra : convert_revision : 38d2629affd964dcd1a5ab0db4ac3cb21438e72c
|
|
encumbered directory
--HG--
extra : convert_revision : 7062ce81183b989f0d922b00d02433633474a854
|
|
they're used
--HG--
extra : convert_revision : ed5351f291d45d585bf811a062e162e16b86e886
|
|
into zazzer.eecs.umich.edu:/z/rdreslin/m5bk/head
--HG--
extra : convert_revision : 8630b3771678b68d5cd12a61f7a4de2e3443a8d7
|
|
03cpu yet.
src/cpu/simple/base.cc:
Cpu's should start as unallocated, not suspended
src/cpu/simple_thread.cc:
Wait for a thread to be assigned to activate the cpu
src/kern/tru64/tru64.hh:
When looking for a open cpu to assign threads, look for an unallocated one, not a suspended one.
--HG--
extra : convert_revision : 5e3ad2e96b4a715ed38293ceaccff5b9f4ea7985
|
|
and python code into m5 to allow swig an python code to
easily added by any SConscript instead of just the one in
src/python. This provides SwigSource and PySource for
adding new files to m5 (similar to Source for C++). Also
provides SimObject for including files that contain SimObject
information and build the m5.objects __init__.py file.
--HG--
extra : convert_revision : 38b50a0629846ef451ed02f96fe3633947df23eb
|
|
or automatically do Split(). It isn't used anywhere, and
isn't very consistent with the python features that are
about to be added. Do accept SCons.Node.FS.File arguments
though.
--HG--
extra : convert_revision : 0f3bb0e9e6806490330eea59a104013042b4dd49
|
|
unproxy() needs to return a new object otherwise all
instances will use the same value. This fix is more
or less unique to NextEthernetAddr because its use of
the proxy stuff is a bit different than everything else.
--HG--
extra : convert_revision : 2ce452e37d00b9ba76b6abfaec0ad2e0073920d7
|
|
to be created
--HG--
extra : convert_revision : 826cc692614528f987c80c3410cb025190f0a4e0
|
|
into ahchoo.blinky.homelinux.org:/home/gblack/m5/newmem-o3-spec
--HG--
extra : convert_revision : 50102b96ba07b2b132d649a111268ee1f08c2147
|
|
--HG--
extra : convert_revision : e81c0337d6db4b5a33381ed19686750bbb9d9178
|
|
implementations from using doubles to using concatenated singles.
--HG--
extra : convert_revision : 609ba35bbb13cbd1998e93957cb051461442d1f9
|
|
into ahchoo.blinky.homelinux.org:/home/gblack/m5/newmem-x86
--HG--
extra : convert_revision : c5275ef3e53393496a2ebe05b2f516884bb392f9
|
|
--HG--
extra : convert_revision : cfebc877b9b2ebc8927ce8267867eb40ad6d59c6
|
|
--HG--
extra : convert_revision : 6c943329525d2a01f35ad5e56ff91505d5011d7b
|
|
--HG--
extra : convert_revision : def1a30e54b59c718c451a631a1be6f8e787e843
|
|
test the stub code for instructions.
--HG--
extra : convert_revision : a377daf20545dfcbb0f97d8cafbe3d68416dc4b2
|
|
parser as a unit.
--HG--
extra : convert_revision : eec4b188b44b80cee643542bbd1aaa139cbc4ef0
|
|
unimplemented instructions in their microcode. This is useful if certain variations of an instruction are implemented, but, for instance, it's memory based versions aren't.
--HG--
extra : convert_revision : 24e69c5a6a0af2d0cf67e858a051ae6624bb300f
|
|
--HG--
extra : convert_revision : 70221349a7100c89be0d03210f3b04950370583f
|
|
--HG--
extra : convert_revision : a582684f3a2dd1d1d0d8b93a9e213d9108491535
|
|
into zamp.eecs.umich.edu:/z/ktlim2/clean/tmp/head
--HG--
extra : convert_revision : a250eed999be9b8acd6f420fdfe8f1b02905beb1
|
|
--HG--
extra : convert_revision : a1a218d3294515184689041487057495223360b7
|
|
into ahchoo.blinky.homelinux.org:/home/gblack/m5/newmem-x86
--HG--
extra : convert_revision : 1396ed5b264d29377ef9793a763225a93181f65f
|
|
--HG--
extra : convert_revision : 1ffe0c497e10fef1eb84b3c97c00b98d820fbb97
|
|
size than the architected one. Also fixed some asserts.
--HG--
extra : convert_revision : 26e7863919d1b976ba8cad747af475a6f18e9440
|
|
into ahchoo.blinky.homelinux.org:/home/gblack/m5/newmem-o3-spec
--HG--
extra : convert_revision : dba3542ab73cc8ae46347a14ae4c133f1276011c
|
|
IsStoreConditional flag needs to be set for them because they aren't store conditional instructions, and I should fix the format code which is not handling the opt_flags correctly.
--HG--
extra : convert_revision : cfd32808592832d7b6fbdaace5ae7b17c8a246e9
|
|
and added some comments to main.isa
--HG--
extra : convert_revision : 1534ae7d5a9e95bf662d79a04f9286c227541c6c
|
|
into ahchoo.blinky.homelinux.org:/home/gblack/m5/newmem-x86
--HG--
extra : convert_revision : 8e624bb95cb9f478ca7ac1dbbd64e20674e3e224
|
|
x86-centric stuff.
--HG--
extra : convert_revision : 5e7e8026e24ce44a3dac4a358e0c3e5560685958
|
|
seperation between x86 specific parts, and those parts which are implemented in the isa description but could eventually be moved elsewhere.
--HG--
rename : src/arch/x86/isa/formats/macroop.isa => src/arch/x86/isa/macroop.isa
extra : convert_revision : 5ab40eedf574fce438d9fe90e00a496dc95c8bcf
|
|
sizes, and sign extend the 32-bit-acting-like-64-bit-immediates.
--HG--
extra : convert_revision : e59b747198cc79d50045bd2dc45b2e2b97bbffcc
|
|
--HG--
extra : convert_revision : 15e3cdb4ebcd31bc44204687ba59dde00c56c6be
|
|
--HG--
extra : convert_revision : 3cf83c3e038fece6190dbb91f56deb0498c9a70d
|
|
into ahchoo.blinky.homelinux.org:/home/gblack/m5/newmem-o3-spec
--HG--
extra : convert_revision : b7e89d32df946ea24c438292308f5fc8248f8bd9
|
|
into ahchoo.blinky.homelinux.org:/home/gblack/m5/newmem-x86
--HG--
extra : convert_revision : efdbf9787383dc1df544b7276f8120285e69bf69
|
|
returned by the decoder has been fleshed out more. The following steps describe how an instruction implementation becomes a StaticInst.
1. Microops are created. These are StaticInsts use templates to provide a basic form of polymorphism without having to make the microassembler smarter.
2. An instruction class is created which has a "templated" microcode program as it's docstring. The template parameters are refernced with ^ following by a number.
3. An instruction in the decoder references an instruction template using it's mnemonic. The parameters to it's format end up replacing the placeholders. These parameters describe a source for an operand which could be memory, a register, or an immediate. It it's a register, the register index is used. If it's memory, eventually a load/store will be pre/postpended to the instruction template and it's destination register will be used in place of the ^. If it's an immediate, the immediate is used. Some operand types, specifically those that come from the ModRM byte, need to be decoded further into memory vs. register versions. This is accomplished by making the decode_block text for these instructions another case statement based off ModRM.
4. Once all of the template parameters have been handled, the instruction goes throw the microcode assembler which resolves labels and creates a list of python op objects. If an operand is a register, it uses a % prefix, an immediate uses $, and a label uses @. If the operand is just letters, numbers, and underscores, it can appear immediately after the prefix. If it's not, it can be encolsed in non nested {}s.
5. If there is a single "op" object (which corresponds to a single microop) the decoder is set up to return it directly. If not, a macroop wrapper is created around it.
In the future, I'm considering seperating the operand type specialization from the template substitution step. A problem this introduces is that either the template arguments need to be kept around for the specialization step, or they need to be re-extracted. Re-extraction might be the way to go so that the operand formats can be coded directly into the micro assembler template without having to pass them in as parameters. I don't know if that's actually useful, though.
src/arch/x86/isa/decoder/one_byte_opcodes.isa:
src/arch/x86/isa/microasm.isa:
src/arch/x86/isa/microops/microops.isa:
src/arch/x86/isa/operands.isa:
src/arch/x86/isa/microops/base.isa:
Implemented polymorphic microops and changed around the microcode assembler syntax.
--HG--
extra : convert_revision : e341f7b8ea9350a31e586a3d33250137e5954f43
|
|
substitution.
--HG--
extra : convert_revision : ba398e1b434efda28882f159d5a4419302276371
|
|
into ahchoo.blinky.homelinux.org:/home/gblack/m5/newmem-o3-spec
--HG--
extra : convert_revision : 81269f094834f43b4e908321bfce2e031b39d2a4
|
|
--HG--
extra : convert_revision : b02736c627bb9dcf87463a9133e04369b9f8fae2
|
|
into zamp.eecs.umich.edu:/z/ktlim2/clean/tmp/head
--HG--
extra : convert_revision : 7181d8c2ee673322372484cf288a94ebd91b5265
|
|
functions.
src/cpu/o3/alpha/cpu_impl.hh:
Pass ISA-specific O3 CPU to FullO3CPU as a constructor parameter instead of using setCPU functions.
--HG--
extra : convert_revision : 74f4b1f5fb6f95a56081f367cce7ff44acb5688a
|
|
into zeep.pool:/z/saidi/work/m5.newmem
--HG--
extra : convert_revision : be37463ea3ca38ef02ae0b82da0752f240a530d0
|
|
deletePortRefs() is called on it with that port as a parameter.
In this way a MemoryObject can keep a functional port around and give it to anyone who wants to do functional accesses rather
than creating a new one each time.
src/mem/bus.cc:
src/mem/bus.hh:
src/mem/cache/cache_impl.hh:
only keep around one func port we give to anyone who wants it. Otherwise we can run out of port ids reasonably quickly if
a lot of functional accesses are happening (e.g. remote debugging, dprintk, etc)
--HG--
extra : convert_revision : 6a9e3e96f51cedaab6de1b36cf317203899a3716
|