variables. Similarly, we could
> remove the common build directory. These things would solve some of the
> problems you enumerate without breaking compatibility. It's definitely
> low-hanging fruit.
>
Yes, exactly, that's my plan.
>
> Cheers,
> Jason
>
>
>
&
Hi folks. I have a design document here:
https://docs.google.com/document/d/11KspjOClPzGRqLUgNTfKQPrrkmsqx-2ulC71nZUJ2qA/edit?usp=sharing
which describes my proposal to overhaul how gem5 builds are configured.
Please take a look and provide feedback.
Important points to note are (optionally but
Hey testing folks (primarily Bobby probably?). I'm revamping the x86
microcode to extract it from SCons itself, and also just to make it less
painful and annoying to work with.
Importantly, the microcode basically lists a sequence of microop mnemonics
and a set of arguments. The mnemonic simply
HimemX 3.34 [Sep 05 2015] (c) 1995, Till Gerken 2001-2006 Tom Ehlert
Always on A20 method used
Kernel: allocated 45 Diskbuffers = 23940 Bytes in HMA
FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00]
Done processing startup files C:\FDCONFIG.SYS and C:\AUTOEXEC.BAT
Type HELP to get
It seems slow, and I had to fix a bug in SeaBIOS, but it seems to run :-)
No video currently, since I haven't written a VGA device yet.
Gabe
On Tue, Jan 18, 2022 at 9:03 PM Gabe Black wrote:
> HimemX 3.34 [Sep 05 2015] (c) 1995, Till Gerken 2001-2006 Tom Ehlert
> Always on A20 method used
>
BTW, I've started trying to get this test program to run to flush out bugs
in our pre-64bit x86 support. It's been very helpful and usable, and I'm
hoping once I get it working (or at least mostly working :-) we can add it
as a regression.
https://github.innominds.com/barotto/test386.asm
Gabe
The bug in SCons was fixed in version 3.0.2. I have a CL which updates the
required version here:
https://gem5-review.googlesource.com/c/public/gem5/+/58629
I'm assuming some docker configuration something will need to be updated to
use SCons version 3.0.2 instead of the 3.0.1 it seems to be
Well, in that case, we could detect version 3.0.1 (there is a function to
get the version I believe) and do the monkey patch they suggest in the
email. The fix was just adding that little function they show, which did
not exist at all in version 3.0.1. I would have to look up exactly how you
I think this is actually a bug in SCons. This docker image seems to be
using the minimum version of it we support, which I think is where the
problem is coming from and not the compiler versions. There is a
"fix"/workaround in this email thread which I haven't tried yet, and which
is a bit of a
https://gem5-review.googlesource.com/c/public/gem5/+/58633
On Tue, Apr 5, 2022 at 7:52 PM Jason Lowe-Power wrote:
> That sounds like a great middle ground.
>
> We could *probably* drop support for 18.04 in v22.0, but we should have a
> broader discussion and make sure that's our intention. It's
This is to mimic systemc's protocol extension mechanism, where you can add
side channel info to a transaction. Sender state is more for keeping track
of information the sender needs related to a particular packet, rather than
to send additional state down the line to other consumers. For instance,
Hi folks. Yan Lee, a Google colleague of mine, is interested in adding one
or more extension objects to gem5 Packet. Systemc has a mechanism like this
already, and it's come up a few times where we've wanted to have something
like this on the gem5 side as well.
Yan, can you please talk about the
501 - 512 of 512 matches
Mail list logo