Hello Andreas, Thank your for your quick response. I am all set to post my small patches, once I resolve my current issue with registration on reviewboard.
Thanks again, -Rizwana On Tue, Feb 10, 2015 at 12:13 PM, Andreas Hansson <[email protected]> wrote: > Hi Rizwana, > > Thanks for the extensive testing. These two regressions have the same > differences on our internal runs, so don’t worry about them for now. I > don’t know why we see these small differences with the official gem5 > regression machine (zizzer), and valgrind and UBSan give no clues. > > Andreas > > From: Rizwana Begum <[email protected]> > Date: Tuesday, 10 February 2015 16:23 > > To: Andreas Hansson <[email protected]> > Cc: gem5 users mailing list <[email protected]> > Subject: Re: [gem5-users] DRAMCtrl auto precharge logic simplification > > Hello Andreas, > > I made changes to the source code to fix android disk name search and > ran quick regression tests, and they passed. I also ran long regressions to > just make sure that nothing is broken. I observed two "changed" tests. So, > I went back and ran long regressions on fresh gem5 repo, and still ended up > with two similar "changed" test cases: > > *Changed:* > *1)* > system.cpu0.iew.predictedTakenIncorrect 287589 287591 2 > +0.00% > system.cpu0.iew.branchMispredicts 683109 683111 2 > +0.00% > > ***** > build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview-o3-dual > CHANGED! > *2)* > system.physmem_0.actBackEnergy 68919855390 68915344410 -4510980 > -0.01% > system.physmem_0.totalEnergy 1860855224610 1860850713630 -4510980 > -0.00% > system.physmem_0.averagePower 667.510956 667.510917 -0.000039 -0.00% > > ***** > build/ARM/tests/opt/long/fs/10.linux-boot/arm/linux/realview-switcheroo-full > CHANGED! > > *Errors:* > Maximum error magnitude: +0.000695% > Maximum error magnitude: +0.006545% > > For both test cases, there is no change in key statistics. Is this error > considered small and can be ignored? Or, you have successful regressions > for long as well with no errors on recent gem5-dev repo (If so, I will > consider debugging it further)? > > Thank you for all your help so far. > > Best, > -Rizwana > > On Thu, Feb 5, 2015 at 3:46 AM, Andreas Hansson <[email protected]> > wrote: > >> Hi Rizwana, >> >> Looks good to me. Could you post a patch on RB? >> >> Thanks, >> >> Andreas >> >> From: Rizwana Begum <[email protected]> >> Date: Wednesday, 4 February 2015 22:57 >> >> To: Andreas Hansson <[email protected]> >> Cc: gem5 users mailing list <[email protected]> >> Subject: Re: [gem5-users] DRAMCtrl auto precharge logic simplification >> >> Hello Andreas, >> >> Sure. However, the warning will not be printed if I unset M5_PATH and >> change SysPaths.py to point to system files. >> I think FSConfig.py can be modified to look for 'android' only in image >> name instead of full path, changing it from >> >> if mdesc.disk().lower().count('android'): >> cmdline += " init=/init " >> >> to >> >> if (os.path.split(mdesc.disk())[-1]).lower().count('android'): >> cmdline += " init=/init " >> >> Thanks, >> -Rizwana >> >> On Wed, Feb 4, 2015 at 4:26 PM, Andreas Hansson <[email protected]> >> wrote: >> >>> Hi Rizwana, >>> >>> Ouch. Is there anyway we could warn for this? Perhaps just warn if >>> android is in the M5_PATH rather than the disk image name? >>> >>> Andreas >>> >>> From: Rizwana Begum <[email protected]> >>> Date: Wednesday, 4 February 2015 20:59 >>> >>> To: Andreas Hansson <[email protected]> >>> Cc: gem5 users mailing list <[email protected]> >>> Subject: Re: [gem5-users] DRAMCtrl auto precharge logic simplification >>> >>> Hello Andreas, >>> >>> I finally have successful regressions. Sigh! >>> >>> my M5_PATH had 'android' key word in it >>> (/home/rizwana/gem5-android/gem5/system/), and because of that 'init=/init' >>> was appended to boot_osflags in FSConfig.py. That resulted in more >>> instructions and caused mismatch in stats. I just renamed my working >>> directory to not have 'android' in path and regressions passed. >>> >>> Thank you, >>> -Rizwana >>> >>> On Wed, Feb 4, 2015 at 9:32 AM, Rizwana Begum <[email protected]> >>> wrote: >>> >>>> Hello Andreas, >>>> >>>> Okay. Yes, I think problem is somewhere on my end. One of my >>>> colleagues ran the regression tests, and they passed for him too. The only >>>> difference is that my tests were on *changeset: 10667:e17949745150 *(tip >>>> as of yesterday)*, *and he ran tests on latest *changeset: >>>> 10680:7639c17357dc *(current tip) . I am running tests now on that to >>>> see if that makes any difference (I am doubtful as I believe all gem5 >>>> commits should pass the regression tests, but there is nothing else that >>>> pops out at me.). >>>> >>>> Thank you, >>>> -Rizwana >>>> >>>> On Wed, Feb 4, 2015 at 8:48 AM, Andreas Hansson < >>>> [email protected]> wrote: >>>> >>>>> Hi Rizwana, >>>>> >>>>> I created a minty fresh VM with Ubuntu 14.04 and the ARM regressions >>>>> pass just fine both with gcc and clang. >>>>> >>>>> Andreas >>>>> >>>>> From: Andreas Hansson <[email protected]> >>>>> Date: Wednesday, 4 February 2015 08:52 >>>>> To: Rizwana Begum <[email protected]> >>>>> >>>>> Cc: gem5 users mailing list <[email protected]> >>>>> Subject: Re: [gem5-users] DRAMCtrl auto precharge logic simplification >>>>> >>>>> Hi Rizwana, >>>>> >>>>> The regressions run fine on a rather large selection of hosts and >>>>> compilers (OS X, RHE5, RHE6, Ubuntu 10.04, Ubuntu 12.04, with gcc 4.6 all >>>>> the way to 4.9, and clang 3.1). I cannot imagine Ubuntu 14.04 should cause >>>>> problems. The thing that makes me most suspicious is that you get >>>>> different >>>>> results when re-running the same tests. There is no non-determinism in the >>>>> simulator, and the results should be the same every time. We have done >>>>> quite a lot of “linting” and an ARM regression run with UBSan switched on >>>>> shows no run-time errors at all. >>>>> >>>>> Is anyone else having these issues? >>>>> >>>>> Andreas >>>>> >>>>> From: Rizwana Begum <[email protected]> >>>>> Date: Wednesday, 4 February 2015 05:23 >>>>> To: Andreas Hansson <[email protected]> >>>>> Cc: gem5 users mailing list <[email protected]> >>>>> Subject: Re: [gem5-users] DRAMCtrl auto precharge logic simplification >>>>> >>>>> Hello Andreas, >>>>> >>>>> This is really strange. I cloned the repo and downloaded the system >>>>> files again. The errors still don't go away. I tried for 'fast' binary as >>>>> well and the errors persist. I am trying it all on Ubuntu 14.04. What host >>>>> OS do you use? I also noticed that number of these errors vary from run to >>>>> run. I am planning to run long ones tonight, will let you know if those >>>>> run >>>>> fine or result in errors. >>>>> >>>>> Thank you, >>>>> -Rizwana >>>>> >>>>> On Tue, Feb 3, 2015 at 4:56 PM, Andreas Hansson < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Rizwana, >>>>>> >>>>>> That is strange. I just cloned the repo and ran with the files from >>>>>> http://www.gem5.org/dist/current/arm/aarch-system-2014-10.tar.xz without >>>>>> any problems. >>>>>> >>>>>> Could you do a clean build and re-download just to be sure? >>>>>> >>>>>> Andreas >>>>>> >>>>>> From: Rizwana Begum <[email protected]> >>>>>> Date: Tuesday, 3 February 2015 21:49 >>>>>> >>>>>> To: Andreas Hansson <[email protected]> >>>>>> Cc: gem5 users mailing list <[email protected]> >>>>>> Subject: Re: [gem5-users] DRAMCtrl auto precharge logic >>>>>> simplification >>>>>> >>>>>> Hi Andreas, >>>>>> >>>>>> Here are the ones that changed: >>>>>> >>>>>> ***** >>>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-atomic >>>>>> CHANGED! >>>>>> ***** >>>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-atomic-dual >>>>>> CHANGED! >>>>>> ***** >>>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-timing >>>>>> CHANGED! >>>>>> ***** >>>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-timing-dual >>>>>> CHANGED! >>>>>> ***** >>>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-switcheroo-atomic >>>>>> CHANGED! >>>>>> ***** >>>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview64-simple-atomic >>>>>> CHANGED! >>>>>> ***** >>>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview64-simple-atomic-dual >>>>>> CHANGED! >>>>>> ***** >>>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview64-simple-timing >>>>>> CHANGED! >>>>>> ***** >>>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview64-simple-timing-dual >>>>>> CHANGED! >>>>>> ***** >>>>>> build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview64-switcheroo-atomic >>>>>> CHANGED! >>>>>> >>>>>> Thank you, >>>>>> -Rizwana >>>>>> >>>>>> On Tue, Feb 3, 2015 at 4:04 PM, Andreas Hansson < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Rizwana, >>>>>>> >>>>>>> That doesn’t sound good. Let me double check the system files. >>>>>>> >>>>>>> Which regressions are “changed"? >>>>>>> >>>>>>> Andreas >>>>>>> >>>>>>> From: Rizwana Begum <[email protected]> >>>>>>> Date: Tuesday, 3 February 2015 21:01 >>>>>>> >>>>>>> To: Andreas Hansson <[email protected]> >>>>>>> Cc: gem5 users mailing list <[email protected]> >>>>>>> Subject: Re: [gem5-users] DRAMCtrl auto precharge logic >>>>>>> simplification >>>>>>> >>>>>>> Hello Andreas, >>>>>>> >>>>>>> I ran the tests again and they result in similar errors (magnitude >>>>>>> error %) in stats. When I don't specify the paths to system files, tests >>>>>>> fail complaining about system files path. I ran tests on my local Ubuntu >>>>>>> (14.04) as well as on a CentOS 5 server, both result in similar errors. >>>>>>> Though none of the tests fail, I don't have clean regression tests (I >>>>>>> only >>>>>>> tried quick ones). I have following gem5 commit: >>>>>>> >>>>>>> *changeset: 10667:e17949745150* >>>>>>> *tag: tip* >>>>>>> *user: Malek Musleh <[email protected] >>>>>>> <[email protected]>>* >>>>>>> *date: Fri Jan 30 15:49:34 2015 -0600* >>>>>>> *summary: config: arm: fix os_flags* >>>>>>> >>>>>>> All I did was cloned gem5-dev repository, compiled ARM opt binary >>>>>>> (scons build/ARM/gem5.opt), downloaded system files, placed the binaries >>>>>>> and disks folder in *system* folder, pointed to the *system* folder >>>>>>> in SysPaths.py, and then ran quick regressions (scons >>>>>>> build/ARM/tests/opt/quick). >>>>>>> >>>>>>> Any help to resolve this issue would be great. >>>>>>> >>>>>>> Thank you, >>>>>>> -Rizwana >>>>>>> >>>>>>> On Tue, Feb 3, 2015 at 12:02 PM, Rizwana Begum < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hello Andreas, >>>>>>>> >>>>>>>> I ran tests on clean repo (without any source code >>>>>>>> modifications), however, I had modified SysPaths.py to point to >>>>>>>> binaries, >>>>>>>> disks downloaded from gem5 download page (ARM Full-System Files >>>>>>>> <http://www.gem5.org/dist/current/arm/aarch-system-2014-10.tar.xz>). >>>>>>>> I am not sure, if that caused the tests to use different kernel/disk >>>>>>>> image >>>>>>>> than the default ones. I compiled opt binary and ran quick tests on opt >>>>>>>> (scons build/ARM/tests/opt/quick). >>>>>>>> >>>>>>>> I am running tests now without modifications to SysPaths.py. I >>>>>>>> will let you know if my results would change. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> -Rizwana >>>>>>>> >>>>>>>> On Tue, Feb 3, 2015 at 11:04 AM, Andreas Hansson < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi Rizwana, >>>>>>>>> >>>>>>>>> There should be no stats changes at all on the trunk. The >>>>>>>>> regression runs from yesterday confirms this as well. Are you sure >>>>>>>>> you ran >>>>>>>>> with a clean repo? >>>>>>>>> >>>>>>>>> Andreas >>>>>>>>> >>>>>>>>> From: Rizwana Begum <[email protected]> >>>>>>>>> Date: Tuesday, 3 February 2015 15:44 >>>>>>>>> To: Andreas Hansson <[email protected]> >>>>>>>>> Cc: gem5 users mailing list <[email protected]> >>>>>>>>> Subject: Re: [gem5-users] DRAMCtrl auto precharge logic >>>>>>>>> simplification >>>>>>>>> >>>>>>>>> Hello Andreas, >>>>>>>>> >>>>>>>>> Yes, the condition will still consider bank conflicts for >>>>>>>>> open-adaptive policy. >>>>>>>>> >>>>>>>>> I made the fix and ran quick regression tests for ARM. All of >>>>>>>>> the tests passed, however there are some errors(in % difference) in >>>>>>>>> results. Here is the output before and after the fix (grep for error): >>>>>>>>> >>>>>>>>> *gem5-dev tip (before fix):* >>>>>>>>> Maximum error magnitude: +68.750000% >>>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>>> Maximum error magnitude: +89.743590% >>>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>>> Maximum error magnitude: +9999.000000% >>>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>>> Maximum error magnitude: +9999.000000% >>>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>>> Maximum error magnitude: +68.750000% >>>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>>> >>>>>>>>> *With fix:* >>>>>>>>> Maximum error magnitude: +6.666667% >>>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>>> Maximum error magnitude: +9999.000000% >>>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>>> Maximum error magnitude: +9999.000000% >>>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>>> Maximum error magnitude: +9999.000000% >>>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>>> Maximum error magnitude: +38.862333% >>>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>>> Maximum error magnitude: +68.750000% >>>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>>> Maximum error magnitude: +89.743590% >>>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>>> Maximum error magnitude: +9999.000000% >>>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>>> Maximum error magnitude: +9999.000000% >>>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>>> Maximum error magnitude: +68.750000% >>>>>>>>> [... showing top 20 errors only, additional errors omitted ...] >>>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>>> Maximum error magnitude: +0.000000% >>>>>>>>> >>>>>>>>> Is this a concern? or can I ignore these errors? >>>>>>>>> >>>>>>>>> PS: Attached full output of quick regression tests. >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> -Rizwana >>>>>>>>> >>>>>>>>> On Tue, Feb 3, 2015 at 3:57 AM, Andreas Hansson < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi Rizwana, >>>>>>>>>> >>>>>>>>>> I look forward to see the patch. >>>>>>>>>> >>>>>>>>>> Note that open-adaptive and closed-adaptive behave differently. >>>>>>>>>> In the open case we only close if there is no hit, and there is a >>>>>>>>>> bank >>>>>>>>>> conflict. For the closed one we close if there are no hits (ignoring >>>>>>>>>> if >>>>>>>>>> there are conflicts or not). If this is till captured then by all >>>>>>>>>> means go >>>>>>>>>> ahead and simplify the code. Perhaps add some more comments to make >>>>>>>>>> this >>>>>>>>>> more clear. >>>>>>>>>> >>>>>>>>>> Andreas >>>>>>>>>> >>>>>>>>>> From: Rizwana Begum via gem5-users <[email protected]> >>>>>>>>>> Reply-To: Rizwana Begum <[email protected]>, gem5 users >>>>>>>>>> mailing list <[email protected]> >>>>>>>>>> Date: Tuesday, 3 February 2015 05:01 >>>>>>>>>> To: gem5 users mailing list <[email protected]> >>>>>>>>>> Subject: [gem5-users] DRAMCtrl auto precharge logic >>>>>>>>>> simplification >>>>>>>>>> >>>>>>>>>> Hello All, >>>>>>>>>> >>>>>>>>>> I think the if condition that's checking to find the right >>>>>>>>>> condition for auto-precharge in doDRAMAccess() can be simplified >>>>>>>>>> >>>>>>>>>> Original : >>>>>>>>>> while (!(got_more_hits && >>>>>>>>>> (got_bank_conflict || pageMgmt == >>>>>>>>>> Enums::close_adaptive)) && >>>>>>>>>> p != queue.end()) { >>>>>>>>>> >>>>>>>>>> Simplified: >>>>>>>>>> while (!got_more_hits && p != queue.end()) { >>>>>>>>>> >>>>>>>>>> The above simplification comes as both close-adaptive and >>>>>>>>>> open-adaptive policies keep row open if a hit is found. Otherwise the >>>>>>>>>> search for a hit continues until the end of the queue and during the >>>>>>>>>> search >>>>>>>>>> got_bank_conflict gets updated anyways. >>>>>>>>>> >>>>>>>>>> I am planning to put this simplification on reviewboard (along >>>>>>>>>> with another bug fix that I have). I would appreciate it if anyone >>>>>>>>>> using >>>>>>>>>> DRAM controller has any comments regarding this simplification. >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> -Rizwana >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- IMPORTANT NOTICE: The contents of this email and any >>>>>>>>>> attachments are confidential and may also be privileged. If you are >>>>>>>>>> not the >>>>>>>>>> intended recipient, please notify the sender immediately and do not >>>>>>>>>> disclose the contents to any other person, use it for any purpose, >>>>>>>>>> or store >>>>>>>>>> or copy the information in any medium. Thank you. >>>>>>>>>> >>>>>>>>>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 >>>>>>>>>> 9NJ, Registered in England & Wales, Company No: 2557590 >>>>>>>>>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge >>>>>>>>>> CB1 9NJ, Registered in England & Wales, Company No: 2548782 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- IMPORTANT NOTICE: The contents of this email and any >>>>>>>>> attachments are confidential and may also be privileged. If you are >>>>>>>>> not the >>>>>>>>> intended recipient, please notify the sender immediately and do not >>>>>>>>> disclose the contents to any other person, use it for any purpose, or >>>>>>>>> store >>>>>>>>> or copy the information in any medium. Thank you. >>>>>>>>> >>>>>>>>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 >>>>>>>>> 9NJ, Registered in England & Wales, Company No: 2557590 >>>>>>>>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge >>>>>>>>> CB1 9NJ, Registered in England & Wales, Company No: 2548782 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- IMPORTANT NOTICE: The contents of this email and any attachments >>>>>>> are confidential and may also be privileged. If you are not the intended >>>>>>> recipient, please notify the sender immediately and do not disclose the >>>>>>> contents to any other person, use it for any purpose, or store or copy >>>>>>> the >>>>>>> information in any medium. Thank you. >>>>>>> >>>>>>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >>>>>>> Registered in England & Wales, Company No: 2557590 >>>>>>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 >>>>>>> 9NJ, Registered in England & Wales, Company No: 2548782 >>>>>>> >>>>>> >>>>>> >>>>>> -- IMPORTANT NOTICE: The contents of this email and any attachments >>>>>> are confidential and may also be privileged. If you are not the intended >>>>>> recipient, please notify the sender immediately and do not disclose the >>>>>> contents to any other person, use it for any purpose, or store or copy >>>>>> the >>>>>> information in any medium. Thank you. >>>>>> >>>>>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >>>>>> Registered in England & Wales, Company No: 2557590 >>>>>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 >>>>>> 9NJ, Registered in England & Wales, Company No: 2548782 >>>>>> >>>>> >>>>> >>>>> -- IMPORTANT NOTICE: The contents of this email and any attachments >>>>> are confidential and may also be privileged. If you are not the intended >>>>> recipient, please notify the sender immediately and do not disclose the >>>>> contents to any other person, use it for any purpose, or store or copy the >>>>> information in any medium. Thank you. >>>>> >>>>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >>>>> Registered in England & Wales, Company No: 2557590 >>>>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 >>>>> 9NJ, Registered in England & Wales, Company No: 2548782 >>>>> >>>> >>>> >>> >>> -- IMPORTANT NOTICE: The contents of this email and any attachments are >>> confidential and may also be privileged. If you are not the intended >>> recipient, please notify the sender immediately and do not disclose the >>> contents to any other person, use it for any purpose, or store or copy the >>> information in any medium. Thank you. >>> >>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >>> Registered in England & Wales, Company No: 2557590 >>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 >>> 9NJ, Registered in England & Wales, Company No: 2548782 >>> >> >> >> -- IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy the >> information in any medium. Thank you. >> >> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >> Registered in England & Wales, Company No: 2557590 >> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >> Registered in England & Wales, Company No: 2548782 >> > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2548782 >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
