nathan binkert wrote:
The reason I'd want to enumerate children is so I can find any memory
objects below the CPU and determine what available ranges I can add into
the map. If there ends up being in-memory-system address transformation
in the future that could be more complicated, but for
On Mon, 14 Jul 2008, nathan binkert wrote:
I'm not disagreeing (yet!), I'm just trying to figure out exactly what
you mean. My original intention was not to modify assert, but to
provide a different macro that acts like assert only with these extra
features. I figured as long as I don't
Anybody? I probably won't have a lot of M5 time until maybe Thursday, but
I'd like to have a discussion going by then about these two functions if
it's warranted. I'll assume if nobody says anything by then I should do
whatever I want to push those out of the CPU.
Gabe
On Thu, 10 Jul 2008,
Actually, the stat is pretty ISA specific as well. I'll have to remember
to look at how things are structured, but it might make sense to stick the
kernel stat object onto the system or cpu objects and get at it through
some path in the thread context. If those stats are per system then I
I didn't know that. I've looked at some code in QEMU and/or boches and/or
PTLsim at various points, and one impression I got was that it would
generally be as much work steal bits of code than to reimplement things
directly because of the architectural differences. They're definitely good
I noticed just now that scons had been stalled out partially through
compilation on something I fired off two days ago. I was using it again
today, and I noticed that it was doing the same thing every now and then.
If I kill it and restart the compilation, it continues to completion and
First, I was hoping to try out the patchbomb extension to send these to
the list, but unfortunately since my smtp setup is still broken that won't
work.
These are some patches that fix some bugs in the params system. I don't
fully understand why the pyobjectfix.patch is necessary, but things
On Sat, 9 Aug 2008, nathan binkert wrote:
First, I was hoping to try out the patchbomb extension to send these to the
list, but unfortunately since my smtp setup is still broken that won't work.
I actually just tell patchbomb to use smtp.gmail.com with my username
and password. Works just
this error? I'd like to fix it correctly.
Nate
2008/8/7 Gabriel Michael Black [EMAIL PROTECTED]:
First, I was hoping to try out the patchbomb extension to send these to the
list, but unfortunately since my smtp setup is still broken that won't work.
These are some patches that fix some bugs
I'm not entirely sure what you're trying to do, but it sounds like you
could build a tracer which just plugs into the CPU. The one you get with
Exec is set up by default, but it's designed so you can easily swap
something else in. This may not work for some reason since I don't quite
get what
We should probably have a regression like that then?
Gabe
On Mon, 20 Oct 2008, Ali Saidi wrote:
No regressions break, but any simulation that includes a detailed cpu
in alpha fs does.
Ali
On Oct 20, 2008, at 12:57 PM, Gabe Black wrote:
I'm in Michigan visiting family at the moment, but
How new can a distro be and still not have 0.98? I realize there's
probably a big range, but what's a reasonable approximation?
Gabe
Quoting Ali Saidi sa...@umich.edu:
What are the specific warts and in what version are they fixed?
Ali
On Feb 9, 2009, at 2:09 PM, nathan binkert wrote:
:19 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
I have a patch in my queue which, for reasons I can get into if people
are interested, prevents fetching in the simple CPU while in the
middle of a macroop. A side effect of this is that benchmarks on the
timing simple CPU have ~25
Quoting nathan binkert n...@binkert.org:
I don't get a holiday Monday... bummer. I'm free pretty much all day
though. I'm also free Tue afternoon and Wed afternoon exc. 2:30-3.
Tue/Wed evenings are bad for me.
Tuesday and Wednesday afternoons wouldn't be great for me since I'd
probably
A long time ago we talked about making some sort of hierarchy for
SimObjects so that they could mirror the namespaces in C++. That way I
wouldn't have to put IntelMP at the beginning of the name of all the
Intel MP table objects. In that case we'd want the python
package/directory
I haven't looked at this incredibly closely yet, but I have a few
questions. First, what's this mt.hh file? You made it an ISA switched
header, but I don't see anything by that name being added. What does
it do?
Second, you shouldn't add a comment out include of cpu/inorder/cpu.hh.
Third,
Why is the in order model asking for O3 source files to be compiled in
the first place?
Gabe
Quoting Korey Sewell ksew...@umich.edu:
changeset 6fd7648e1b8d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=6fd7648e1b8d
description:
Remove unnecessary building of
to obtain would change the style of pipelining. Since M5 already has a
O3 model, then the out of order functionality is no longer required or
desirable for 99% of users.
On Fri, Feb 20, 2009 at 2:46 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
Why is the in order model asking for O3
I'll need to generate updated stats for some of the regressions in at
least two places in the patches beyond these. I'll wait until I have
those ready, and then if no one has said anything I'll assume there
are no complaints and start pushing.
Gabe
Quoting gbl...@eecs.umich.edu:
I got rid of the argument arrays because x86 doesn't always use the
same registers to get a particular argument depending on if you're in
a 32 bit or 64 bit binary. Since the array doesn't exist any more, I
put in a substitute in the few places it had been used directly.
Gabe
Quoting Korey
There's actually a bug in the CPU wakeup code which prevents any CPU
that isn't activated and then suspended, like SPARCs APs which are
suspended directly, from waking up on interrupts, etc. I have a
partial fix which I've been using to work around the problem, but we
need to come up with
Quoting Polina Dudnik pdud...@gmail.com:
On Thu, Mar 5, 2009 at 3:38 PM, Gabriel Michael Black gbl...@eecs.umich.edu
wrote:
There's actually a bug in the CPU wakeup code which prevents any CPU
that isn't activated and then suspended, like SPARCs APs which are
suspended directly, from waking
the partial patch you have?
Thank you.
Polina
On Thu, Mar 5, 2009 at 4:48 PM, Gabriel Michael Black gbl...@eecs.umich.edu
wrote:
Quoting Polina Dudnik pdud...@gmail.com:
On Thu, Mar 5, 2009 at 3:38 PM, Gabriel Michael Black
gbl...@eecs.umich.edu
wrote:
There's actually a bug
Quoting Steve Reinhardt ste...@gmail.com:
On Wed, Mar 4, 2009 at 7:03 AM, Steve Reinhardt ste...@gmail.com wrote:
I think there are two possible solutions:
1. Add a retry response code for atomic requests (along the lines of
the error codes we alrady have in packet.hh) and then make sure that
Quoting Steve Reinhardt ste...@gmail.com:
On Thu, Mar 5, 2009 at 6:33 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
Quoting Steve Reinhardt ste...@gmail.com:
On Wed, Mar 4, 2009 at 7:03 AM, Steve Reinhardt ste...@gmail.com wrote:
I think there are two possible solutions:
1. Add
To give everyone a heads up, I'm going to have family visiting
from March 11th until the 30th and will have very little time for M5
if any. If there's anything important that needs to be done soon, it
will need to be done before Tuesday.
Gabe
I would be happy to, but I don't touch M5 code at work and I'm
spending all my other time with my family while they visit. If anyone
else wants to give it a shot that would be helpful.
Gabe
Quoting Korey Sewell ksew...@umich.edu:
How would you do that?
Can you give an example for the
Does this happen when you start tracing sooner? I'd suggest valgrind,
especially if you can make the segfault happen quickly. If you wait
for your simulation to get to 14000 ticks in valgrind, you may
die before you see the result. There's a suppression file in util
which should
edited that is
tagged when you use ExecEnable rather than just Exec?
Also, if you can turn valgrind on for maybe the 1st thousand/million
cycles with ExecEnable you'll probably find something.
On Thu, Apr 2, 2009 at 7:28 PM, Gabriel Michael Black
gbl...@eecs.umich.edu mailto:gbl
Or to rephrase, should the event be descheduled, or should it still
happen and the IDE disk just deal with it.
Gabe
Quoting Gabe Black gbl...@eecs.umich.edu:
I think what's happening is that the controller is being told to stop
DMAing before it's done. The controller tells the disk to abort
And to clarify, you'd call it before you add in NumIntRegs.
Gabe
Quoting Gabriel Michael Black gbl...@eecs.umich.edu:
This is the right idea but isn't quite right. You need to add in a
call to the flattening function on reg_idx as well, I think. I'm
pretty sure it doesn't do anything
Also, why do you change inst-readNextNPC() to inst-readNextPC()
in iew_impl.hh? Aren't you going to then print the same value twice?
Well, I'm trying to fix error'd DPRINT statements here.
In the DPRINT, it says NPC, but it's printing out the NNPC which was
confusing to me. So maybe the
Quoting Steve Reinhardt ste...@gmail.com:
On Fri, Apr 17, 2009 at 1:37 PM, nathan binkert n...@binkert.org wrote:
I'm not an expert on this code, but I think it's preventing excessively
restarting the CPU if you do a switchover or resume from a checkpoint.
Yea, that's exactly my
Quoting Steve Reinhardt ste...@gmail.com:
On Fri, Apr 17, 2009 at 1:43 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
You should also be sure to test starting from a checkpoint which I
believe is different from a switchover, although I'm not sure.
It shouldn't be different from
Anybody?
Quoting Gabe Black gbl...@eecs.umich.edu:
I reordered my patches so that I could push this, and now all of the
remaining ones are dependent on or are hacks that force there to be two
CPUs. In order to push these last ~5 patches, I need to know how many
CPUs there are when I'm
This sort of question should go to the m5-users mailing list. The
information on
http://m5sim.org/wiki/index.php/Simulation_Scripts_Explained might
help you. You should never need to modify files in build since those
are all either simlinked to files in other places or are generated by
Here is a hypothetical series of events that should hopefully
illustrate what's going on.
1. The store conditional comes up for execution and its initiateAcc is called.
2. initiateAcc calls xc-write() to actually do the required store.
3. write calls into the TLB's translateTiming function to
initiateAcc looks something like the following:
Fault initiateAcc(..., traceData,...)
{
...
write(); traceData becomes invalid in here
if (traceData) traceData-setData(Mem);
...
}
so I'm not sure how that would work.
Gabe
Quoting nathan binkert n...@binkert.org:
7.
Quoting nathan binkert n...@binkert.org:
initiateAcc looks something like the following:
Fault initiateAcc(..., traceData,...)
{
...
write(); traceData becomes invalid in here
if (traceData) traceData-setData(Mem);
...
}
so I'm not sure how that would work.
Why is
This bug happens when both the translation component and the memory
access component finish inline before returning. When that happens,
completeAcc is effectively called from initiateAcc and you get into
trouble.
The translation component will complete inline in all cases except TLB
Quoting nathan binkert n...@binkert.org:
Hi Gabe,
[ I wrote this e-mail almost a month and a half ago and I just noticed
that it never got sent. I think it is still relevant]
I've started looking at your patch and in particular some of the
translation code in the TimingSimpleCPU. I have
Quoting nathan binkert n...@binkert.org:
I think the difference is that passing it in explicitly means that
you could
keep it in a register for the duration of the function, and if you can put
it in a callee-save then maybe you could save a few dereferences. In
contrast the indirection
Quoting Korey Sewell ksew...@umich.edu:
So my original point (that obviously wasnt conveyed very well) was
more trying to re-work how this STL_C case works rather than kind of
patch it up so it works in the current framework.
Seems to be me that completeAcc should never get called before
Quoting nathan binkert n...@binkert.org:
I'm specifically talking about the parameter passed into the exec
function which is either SimpleCPU or BaseDynInst. Those both have a
traceData parameter and it can just be used directly without any fancy
indirection. I am only talking about this
Quoting Korey Sewell ksew...@umich.edu:
This is a problem I ran into with SPARC in O3 because it overlaps its
single and double precision FP registers. The way I worked around it was
to treat all registers as the smallest size, in that case 32 bits, and
then have the instruction glue the bits
Quoting Korey Sewell ksew...@umich.edu:
Unless I'm misunderstanding your question, this does work in O3 with
SPARC because it tracks each single precision floating point register
separately. Each FP instruction is considered to have two sources for
each double precision register it uses, and
Quoting Korey Sewell ksew...@umich.edu:
IMO,
I think there are two issues in play here:
1) For each operand, 2 source registers are needed for FP double
precision access
2) If you want to read these registers *before* execute, how do you
access them separately (in terms of size of access)?
Quoting Steve Reinhardt ste...@gmail.com:
On Sun, May 3, 2009 at 12:09 AM, Gabe Black gbl...@eecs.umich.edu wrote:
While this does avoid the segfault, it also causes some other bug which
crashes just about any of the simple timing regressions. I hadn't
actually tried any of the quick
Great work guys! It would probably be a good idea to also compile with
RUBY=false every now and then to make sure no unintended dependencies
crop up.
Gabe
Quoting nathan binkert n...@binkert.org:
Hi everyone,
I just wanted to let both the GEMS people and the M5 people know that
after
To avoid spamming the other folks on m5-users who might not be
interested in the discussion I'm moving this over to m5-dev.
I think making the ISA a class with only (or mostly) static members
would be reasonable since I expect the compiler would pretty much
figure out they're just in a
That might be a complicated undertaking and may end up being messy,
but it would be nice to unify that code a bit.
Gabe
Quoting nathan binkert n...@binkert.org:
I'm working more on the build infrastructure and one of my long term
goals is to get rid of the FULL_SYSTEM #define. To this end,
Quoting Ali Saidi sa...@umich.edu:
On Tue, 9 Jun 2009 08:30:40 -0700, nathan binkert n...@binkert.org wrote:
These patches touch up our ARM implementation and add in support for
some
new
features including TLS, a page for the kernel to install user level
helper
functions, a few of those
For future reference, if you aren't intending to primarily contribute
what you're working on back to M5, you should use m5-users. It's a
fuzzy distinction but that's the going rule of thumb. More people will
see your question that way too.
Gabe
Quoting Cong Wang jameswan...@yahoo.com:
Hi
I'll look at these in more detail tonight, but thank you in advance
for finding and also fixing these bugs. I'd be willing to believe your
flags for open are right and the ones in M5 are inherited from MIPS,
SPARC, or Alpha, but I don't know that for sure.
There isn't anyone I know of
Quoting Steve Reinhardt ste...@gmail.com:
Sorry for the slow reply... I'm traveling this week.
Likewise, although I don't have a good excuse.
On Sun, Jun 21, 2009 at 10:30 AM, Gabe Black gbl...@eecs.umich.edu wrote:
To differentiate between branch/no branch that's actually along the
lines
Quoting Jack Whitham jack-m5...@cs.york.ac.uk:
On Wed, Jun 24, 2009 at 09:30:11PM -0400, Gabriel Michael Black wrote:
Also, is it the case that you can write the PC with any opcode? I vaguely
recall hearing that that was deprecated at some point.
I don't know. I saw some places
Quoting Steve Reinhardt ste...@gmail.com:
On Mon, Jun 29, 2009 at 6:02 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
That is true, but I think what he's talking about is when the CPSR
doesn't actually matter at all since the condition is always. I
don't know what the best way
This is fine, except it doesn't really address the op_rd and op_wb
issue, ie. having different code to read and write the register
arguments in the execute method. I'd like to have that fixed as soon
since it's holding up some other register file work I'm doing. It's
not critical that that
Part of the problem is that those programs should work in the first
place. I compiled mcf and it crashed, and I wasn't able to compile
twolf and one other benchmark which I'm forgetting right now. We could
verify that it still crashes in the same way, and I guess that would
help determine
Quoting Steve Reinhardt ste...@gmail.com:
On Tue, Jun 30, 2009 at 3:24 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
This is fine, except it doesn't really address the op_rd and op_wb
issue, ie. having different code to read and write the register
arguments in the execute method
Quoting Jack Whitham jack-m5...@cs.york.ac.uk:
On Wed, Jul 01, 2009 at 10:09:55PM -0700, Gabe Black wrote:
I'm going to commit my changes and presume that anything that breaks
will end up being fixed with whatever else may be broken now. I don't
think these changes are likely that broken so
Quoting nathan binkert n...@binkert.org:
- You're guaranteed that any SimObject that is passed to you as a parameter
has been constructed before your constructor is called, so that the pointer
in the params struct is valid. Since init() hasn't been called yet you
can't assume too much about
This is actually my fault, I think. I changed around the code to use
BitUnions and I must have accidentally deleted an = here. I'm pretty
confident it's correct, but if you want to be sure you could look at
the diff of that change and see what the logic used to be. I'm a
little surprised
Confident that this fix is correct, that is. I just checked the diff
of the older change and I did accidentally nuke an =. If you're in a
hurry please go ahead and commit this fix.
Gabe
Quoting Gabriel Michael Black gbl...@eecs.umich.edu:
This is actually my fault, I think. I changed
This would be an overlay instead of indirection. I'd have a uint64_t
that overlapped with several smaller fields. Fewer comparison/xors
would need to be done if you used the uint64_t, and you'd get roughly
equivalent results.
The way bitunions work is that they're a union of classes which
Quoting nathan binkert n...@binkert.org:
Yes and yes. All the bugs I fixed last night I found with a massaged
version of the main test program from there and more will be coming. I'm
definitely planning on using it as a regression in SE, and also as the
program to run in FS once the kernel is
Quoting nathan binkert n...@binkert.org:
The changes I pushed already mostly fix condition codes on existing
instructions, plus rotates by more than the width of the target, plus
a few minor fixes to multiply related microops. Moving forward in the
short term, division instructions aren't
Yes, x87 was superceded by 3dNow! and MMX, those in turn were
superceded by SSE, and it wouldn't surprise me to see some new acronym
come in and replace SSE. It hasn't taken any extrordinary effort to
support both of the newer extensions since they're both SIMD, they
both can be looked at
How difficult would it be to generate a visual graph of the simboject
heirarchy from within a config script? It might look something like
Simulation.graph() similar to Simulation.run(...). I'm thinking
that might be a good sanity check if someone wanted to make sure their
simulation was
Quoting nathan binkert n...@binkert.org:
I have a couple of comments on this changeset. First, I think this
has the potential to affect alpha, so you should run regressions.
(MC146818 is used by alpha for the clock).
That's right, and I did that before I committed. I was a little
Quoting nathan binkert n...@binkert.org:
If it's all UTC then there's no daylight savings issue. Plus given
the rate at which we simulate, we'd have to have a very poorly chosen
starting time date to simulate across a leap second (from
http://en.wikipedia.org/wiki/Leap_second:
Leap seconds
Quoting Steve Reinhardt ste...@gmail.com:
On Tue, Aug 25, 2009 at 6:30 PM, Gabriel Michael
Blackgbl...@eecs.umich.edu wrote:
Actually I was hoping that you wouldn't have to include all the .hh
files. If the main decoder in main_decoder.cc calls out to a
subdecoder for x87 ops in
I'd love to look at these patches more closely too, but I don't know
if I'll have the time in the next several weeks. I also don't think I
got the original email, but that might be the fault of an overzealous
spam filter. Are there changes outside of the assumed new arch/powerpc
directory
Without looking at the actual code, the PC operand class sounds fine.
For when I get a chance to look at your patches in more depth, what
documentation (preferably downloadable) for PowerPC would you recommend?
Gabe
Quoting Timothy M Jones tjon...@inf.ed.ac.uk:
Dear all,
Thanks very much
Quoting nathan binkert n...@binkert.org:
I'm rerunning regressions on zizzer and everything seems fine so
far... this looks like an issue with swig on the pool machines. Does
anyone have any idea why things might have changed (either with the
version of swig on the pool machines, or the
So, in SE mode, is there a distinction made between two threads (workloads)
belonging to the same process and two threads belonging to different
processes? In other words, if I were to spawn two threads from a single
program, would it be possible to run them as two different h/w threads in SE
Hello everybody. I was thinking the other day that it might be a good
idea to templatize readMiscReg and setMiscReg. I don't have the idea
fleshed out all the way, but I thought it would be a good idea to send
an email to before I forgot about it.
When we access control registers, my
You guys have valid points, and I don't know for a fact that the
compiler isn't already giving us the same performance boost this
might. Back that summer when someone looked at increasing performace I
think they got somewhere by moving some common cases out of the switch
statement and into
Thank you for your patches. I'm a little buried right now, but they
are important, I -will- get to them eventually, and they'll more than
likely end up in the tree. Thanks!
Gabe
Quoting Vince Weaver vi...@csl.cornell.edu:
Hello
the loop instructions on x86 are broken, they seem to be
Never mind. I realized what was going on as I was getting ready for
work this morning. imm is the same size for all microops, but when
it's stored internal to the microop it gets truncated into a 16 bit
immediate value. A better solution might be to make the wripi
instruction sign extend
Sorry to yank you around, but I was thinking this was something we
should handle more generally for all buffers that get copied into the
guest. It turns out we do, so the memset was unnecessary. Thanks for
putting it in anyway, though, and thanks for all your patches so far.
We really
Quoting Beckmann, Brad brad.beckm...@amd.com:
Thanks everyone for the comments. I won't be able to check in my
patch(es) today, but will work on it more next week and try to
commit them in a week or two.
First to answer Nate:
- In hindsight, one may see the items in this patch as
Quoting Vince Weaver vi...@csl.cornell.edu:
On Tue, 22 Sep 2009, Gabe Black wrote:
This value was actually based off how Linux set up an actual process on
a real machine. We have a tool that runs processes on a real machine and
compares their execution with M5. I calibrated those constants to
Quoting nathan binkert n...@binkert.org:
For TTY-related ioctls, returning ENOTTY is the right behavior, so
there's no need to print a warning. To me it's a step backward to
start printing a warning for something that we're actually handling
correctly. If we're not properly identifying
Unfortunately it isn't supported right now. The instruction counting
code was present long before uops in any form, and it hasn't been
updated to account for them. I've brought that up before, but we
haven't done anything to address the issue. What I imagine us doing at
some point, and
While thinking about it as I waited for a response I decided the same
thing. I'll implement that when I get a chance.
Gabe
Quoting nathan binkert n...@binkert.org:
Does anyone have an opinion on which is better? I'd like to do use the
first approach, but I'm not sure it's worth the
That sounds like something scons could check for, maybe?
Gabe
Quoting nathan binkert n...@binkert.org:
No. There are some extra dependencies right now. You need to install
the ruby (the language) interpreter. That's what is failing.
Nate
On Thu, Oct 1, 2009 at 12:55 AM, Korey Sewell
I agree with both Ali and Korey that MiscRegs that don't actually
control anything and just pass around data (like condition codes)
should be honorary integer registers. There are a number of examples
of this, some of which are in SPARC specifically.
One issue, though, is that by my
For everybody's reference, this is the CMOS/RTC device that is common
to our Alpha and x86 platforms. I move that code around when I made it
shared between x86 and Alpha. I don't really do anything with
serialization code generally and probably moved it as is. I'll try to
look at this
Thinking about this more, it also seems that NO_FAULT doesn't quite
capture what a prefetch is. If you're doing a load that shouldn't
fault
but still (assuming it worked) return data, that's different from a
prefetch that doesn't return anything. In one case you'd potentially
block
Quoting Ali Saidi sa...@umich.edu:
On Mon, 26 Oct 2009 01:59:14 -0700, Gabe Black gbl...@eecs.umich.edu
wrote:
Ali Saidi wrote:
I believe that the rules are as follows (from some google searches,
but I couldn't find a definitive list):
64 bit arch/app -- Do nothing special
32 bit arch/app
Thanks. I have a half completed change that replaces cryptic ext
constants with more meaningful names, and hopefully that makes those
microops easier to work with in the future.
Gabe
Quoting Vince Weaver vi...@csl.cornell.edu:
This patch adds support for the haddpd sse instruction.
Are you referring to the PageFault in the SE only code in the TLB?
It's really just a signal to the CPU that the translation failed. If
the translation failure was silent, the CPU might still try to do the
access and cause more trouble. Once the fault makes it into the CPU,
it gets
Yes, go for it.
Quoting Vince Weaver vi...@csl.cornell.edu:
On Tue, 3 Nov 2009, Gabe Black wrote:
If you set destSize=8 I think that'll solve the first problem. The
source register is put into a uint64_t, and then that's put into a
destSize sized chunk of the destination register. If you
It looks like there are some extra spaces before the ULLs.
Gabe
Quoting nathan binkert n...@binkert.org:
Looks good to me.
Nate
On Tue, Nov 10, 2009 at 9:21 AM, Vince Weaver vi...@csl.cornell.edu wrote:
On Mon, 9 Nov 2009, nathan binkert wrote:
Can you swap your ULL at the end with
I'm sure you were going to anyway, but please send patches before you
commit anything.
Gabe
Quoting Derek Hower d...@cs.wisc.edu:
I've been working on merging the outstanding changes at Wisconsin over
the past few days. It's been tricky, but hopefully I've completed the
merge without
I looked briefly at that change earlier, and I do think it's likely
that I broke it. I don't know how much time I'll have to dig into it
in the near future, but I'll put it on my short(ish :-/) list.
Gabe
Quoting Matt mattm5u...@gmail.com:
Gabe,
It looks like it was your changes that
Quoting Korey Sewell ksew...@umich.edu:
I haven't checked too carefully, but this same problem may be
affecting ARM as well (since I think it uses the same paired
floating-point register scheme). Also, other double-precision things
like checking for NaNs may be broken by this change.
Yea,
There are a number of things about this patch I like (adding aux
vectors to MIPS, cleaning up some Alpha-isms), but I really don't like
how this gets plumbed explicitly through the CPU and thread contexts.
Why can't this be shoved into a register like it likely is on a real
CPU? How is its
I can't really look at the code at the moment, but from the
description it should be fine.
Gabe
Quoting Ali Saidi sa...@umich.edu:
Great... Gabe, are you satisfied?
Ali
On Dec 14, 2009, at 9:00 AM, soumyaroop roy wrote:
Hi Gabe, Ali,
Updated patch(es) are here:
1 - 100 of 219 matches
Mail list logo
