comp.arch

• Date Index

• RFC - New Object-Oriented Method of Parallel Programming, Slawomir J.
  • Re: RFC - New Object-Oriented Method of Parallel Programming, David Hopwood
• $$ Reward for copy of PCI System Design Guide, Revision 1.0, gwjd
• Where can I find MIPS target support for simplescalar?, unicell
  • Re: Where can I find MIPS target support for simplescalar?, Spoon
• measuring the performance of my code, dialme
  • Re: measuring the performance of my code, Bill Todd
• cache tags, Robert Finch
  • Re: cache tags, David Hopwood
  • Re: cache tags, Andy Glew
    • Re: cache tags, Kai Harrekilde-Petersen
      • Re: cache tags, David Kanter
• Call for papers - WiSec 2006, santosh . pandey
• Variable confidence/urgency prefetch?, Dysthymicdolt
  • Re: Variable confidence/urgency prefetch?, Seongbae Park
    • Re: Variable confidence/urgency prefetch?, Terje Mathisen
      • Re: Variable confidence/urgency prefetch?, Greg Lindahl
      • Re: Variable confidence/urgency prefetch?, Terje Mathisen
• Tag sequential L1 cache in MT processors?, Dysthymicdolt
• Fast Multiplier in ARM Arch, Nishu
  • Re: Fast Multiplier in ARM Arch, Torben Ægidius Mogensen
    • Re: Fast Multiplier in ARM Arch, Wilco Dijkstra
      • Re: Fast Multiplier in ARM Arch, Nishu
      • Re: Fast Multiplier in ARM Arch, Wilco Dijkstra
  • Re: Fast Multiplier in ARM Arch, Peter Dickerson
  • Re: Fast Multiplier in ARM Arch, Paul Gotch
    • Re: Fast Multiplier in ARM Arch, Nishu
• Re: Vectored Interrupt Fetch, Sander Vesik
• IBM Continues Open Source Drive With Eclipse Services and Software Commitments, technology_post
• How to extract the data on bus in SimpleScalar, bgyihsiu
• [OT] Convex c220, Capitan Mutanda
  • Re: [OT] Convex c220, John Savard
    • Re: [OT] Convex c220, Edward A. Feustel
      • Re: [OT] Convex c220, Eugene Miya
      • Re: Convex c220, David Kanter
      • Re: Convex c220, Terje Mathisen
• Data dependency benchmarks, arvind_c_98
• zSeries IT Performance Specialist (B009448) - Full-time Position at IBM, TechRec
• Trapping PPC errors, Matthew Clark
  • Re: Trapping PPC errors, Mikael Pettersson
    • Re: Trapping PPC errors, Matthew Clark
      • Re: Trapping PPC errors, Seongbae Park
      • Re: Trapping PPC errors, Matthew Clark
  • Re: Trapping PPC errors, Niels Jørgen Kruse
    • Re: Trapping PPC errors, Matthew Clark
  • Re: Trapping PPC errors, Spoon
• I Should Surrender to Opteron, John Savard
  • Re: I Should Surrender to Opteron, Thomas Womack
    • Re: I Should Surrender to Opteron, John Savard
      • Re: I Should Surrender to Opteron, Joachim Worringen
      • Re: I Should Surrender to Opteron, anonymous
      • Re: I Should Surrender to Opteron, Jason Lee Eckhardt
      • Re: I Should Surrender to Opteron, Del Cecchi
      • Re: I Should Surrender to Opteron, David Wang
      • Re: I Should Surrender to Opteron, Tim McCaffrey
      • Re: I Should Surrender to Opteron, Greg Lindahl
      • Re: I Should Surrender to Opteron, Tom Knight
      • Re: I Should Surrender to Opteron, Iain McClatchie
      • Re: I Should Surrender to Opteron, David Wang
      • Re: I Should Surrender to Opteron, Del Cecchi
      • Re: I Should Surrender to Opteron, mike
      • Re: I Should Surrender to Opteron, KR Williams
      • Re: I Should Surrender to Opteron, mike
      • Re: I Should Surrender to Opteron, KR Williams
      • Re: I Should Surrender to Opteron, mike
      • Re: I Should Surrender to Opteron, Del Cecchi
      • Re: I Should Surrender to Opteron, mike
      • Re: I Should Surrender to Opteron, Del Cecchi
      • Re: I Should Surrender to Opteron, Del Cecchi
      • Re: I Should Surrender to Opteron, Ketil Malde
  • Re: I Should Surrender to Opteron, Greg Lindahl
  • Re: I Should Surrender to Opteron, Peter Grandi
• interfacing 8254 and 8259 0n a 32-bitprocessor, jim james
• HOTI 14 Call For Papers, lucavc
• Re: IBM whitepaper on FSB snooping, David Kanter
  • Re: IBM whitepaper on FSB snooping, Stephen Fuld
    • Re: IBM whitepaper on FSB snooping, Del Cecchi
      • Re: IBM whitepaper on FSB snooping, Niels Jørgen Kruse
      • Re: IBM whitepaper on FSB snooping, David Kanter
      • Re: IBM whitepaper on FSB snooping, David Kanter
      • Re: IBM whitepaper on FSB snooping, Stephen Fuld
      • Re: IBM whitepaper on FSB snooping, Wilco Dijkstra
      • Re: IBM whitepaper on FSB snooping, Stephen Fuld
      • Re: IBM whitepaper on FSB snooping, Del Cecchi
      • Re: IBM whitepaper on FSB snooping, Stephen Fuld
      • Re: IBM whitepaper on FSB snooping, David Kanter
      • Re: IBM whitepaper on FSB snooping, Niels Jørgen Kruse
      • Re: IBM whitepaper on FSB snooping, Del Cecchi
      • Re: IBM whitepaper on FSB snooping, Andy Glew
• any formula?, priyasmita_guha@xxxxxxxxxxx
  • Re: any formula?, fox
  • Re: any formula?, russell kym horsell
  • Re: any formula?, Torben Ægidius Mogensen
• Simpl, Richard Pennington
  • Re: Simpl, Richard Pennington
• Question about architectural practice in industry, Julian Kain
  • Re: Question about architectural practice in industry, JJ
    • Re: Question about architectural practice in industry, David Kanter
• Hardware poweroff disable, ahmed . sharifi
• The death of the BIG ENDIAN, atbusbook
  • Message not available
    • Re: The death of the BIG ENDIAN, KR Williams
  • Re: The death of the BIG ENDIAN, David Hopwood
  • Re: The death of the BIG ENDIAN, randyhyde@xxxxxxxxxxxxx
  • Re: The death of the BIG ENDIAN, John Savard
    • Re: The death of the BIG ENDIAN, Dan Koren
• Call for Papers (extended): IAENG International Workshop on Scientific Computing and Computational Statistics (in IMECS 2006), imecs__2006
• Pipelining without forwarding but allowing register read-write back, mihir
  • <Possible follow-ups>
  • Pipelining without forwarding but allowing register read-write back, mihir
  • Pipelining without forwarding but allowing register read-write back, mihir
    • Re: Pipelining without forwarding but allowing register read-write back, Tommy Thorn
    • Re: Pipelining without forwarding but allowing register read-write back, Stefan Monnier
• About trace-driven multi-processor simulation, Auhgnist
• Re: MOESI protocol, Sander Vesik
  • Re: MOESI protocol, Joe Pfeiffer
• Benchmark, mihir
  • Re: Benchmark, Patrick Schaaf
  • Re: Benchmark, MitchAlsup
  • Message not available
    • Re: Benchmark, robert . thorpe
  • Message not available
    • Re: Benchmark, Stephen Fuld
• available literature in the net, daemon
  • Re: available literature in the net, David Kanter
• Hardware support for preemption detection, Piotr Wyderski
  • Re: Hardware support for preemption detection, ajv-ovenuousey
    • Re: Hardware support for preemption detection, Piotr Wyderski
      • Re: Hardware support for preemption detection, Joe Seigh
      • Re: Hardware support for preemption detection, Piotr Wyderski
      • Re: Hardware support for preemption detection, Joe Seigh
• The real details on Intel's Core microarchitecture, David Kanter
• Sell high quality HDI PCB (CHINA), njsldz@xxxxxxx
  • Re: Sell high quality HDI PCB (CHINA), njsldz@xxxxxxx
• Intel Core Architecture, Tim McCaffrey
  • Message not available
    • Re: Intel Core Architecture, Stephen Sprunk
  • Re: Intel Core Architecture, David Ball
    • Re: Intel Core Architecture, Stephen Sprunk
    • Re: Intel Core Architecture, Joe Pfeiffer
      • Re: Intel Core Architecture, David Ball
      • Re: Intel Core Architecture, David Kanter
  • Re: Intel Core Architecture, Michael Koenig
    • Re: Intel Core Architecture, David Kanter
• SIMD/Vector benchmarks, silk . morton
  • Re: SIMD/Vector benchmarks, Peter Matthias
    • Message not available
      • Re: SIMD/Vector benchmarks, Dr. Adrian Wrigley
      • Message not available
      • Re: SIMD/Vector benchmarks, Dr. Adrian Wrigley
      • Re: SIMD/Vector benchmarks, Eugene Miya
      • Re: SIMD/Vector benchmarks, David DiNucci
      • Re: SIMD/Vector benchmarks, Eugene Miya
      • Re: SIMD/Vector benchmarks, David DiNucci
      • Re: SIMD/Vector benchmarks, Eugene Miya
      • Re: SIMD/Vector benchmarks, josmala@xxxxxxxxx
      • Message not available
      • Re: SIMD/Vector benchmarks, Eugene Miya
  • Re: SIMD/Vector benchmarks, Peter Grandi
• Double-word LL/SC on PowerPC, Piotr Wyderski
• 64-bit architectures & 32-bit instructions, silk . morton
  • Re: 64-bit architectures & 32-bit instructions, Rock
    • Re: 64-bit architectures & 32-bit instructions, silk . morton
      • Re: 64-bit architectures & 32-bit instructions, Patrick Schaaf
      • Re: 64-bit architectures & 32-bit instructions, silk . morton
      • Re: 64-bit architectures & 32-bit instructions, Thomas Womack
      • Re: 64-bit architectures & 32-bit instructions, Rob Warnock
      • Re: 64-bit architectures & 32-bit instructions, Seongbae Park
  • Re: 64-bit architectures & 32-bit instructions, john Doef
    • Re: 64-bit architectures & 32-bit instructions, John Mashey
    • Re: 64-bit architectures & 32-bit instructions, Sander Vesik
  • Re: 64-bit architectures & 32-bit instructions, Torben Ægidius Mogensen
  • Re: 64-bit architectures & 32-bit instructions, Michael Koenig
    • Re: 64-bit architectures & 32-bit instructions, Niels Jørgen Kruse
      • Re: 64-bit architectures & 32-bit instructions, Michael Koenig
  • Re: 64-bit architectures & 32-bit instructions, Eugene Miya
    • Re: 64-bit architectures & 32-bit instructions, lynn
• About TLB in lower-level caches, Auhgnist
  • Re: About TLB in lower-level caches, Dale Morris
    • Re: About TLB in lower-level caches, Anne & Lynn Wheeler
      • Re: About TLB in lower-level caches, Andy Glew
      • Re: About TLB in lower-level caches, Anne & Lynn Wheeler
      • Re: About TLB in lower-level caches, Anne & Lynn Wheeler
      • Re: About TLB in lower-level caches, Eric P.
      • Message not available
      • Re: About TLB in lower-level caches, Anne & Lynn Wheeler
      • Message not available
      • Re: About TLB in lower-level caches, Eric P.
      • Message not available
      • Re: About TLB in lower-level caches, Jan Vorbrüggen
      • Re: About TLB in lower-level caches, Anne & Lynn Wheeler
      • Message not available
      • Re: About TLB in lower-level caches, Eric P.
      • Re: About TLB in lower-level caches, Anne & Lynn Wheeler
      • Re: About TLB in lower-level caches, Anne & Lynn Wheeler
• 400+ software to download / search, sales
• Re: C++: 64 bit performance vs. 32 bit, Eliot Miranda
  • Re: C++: 64 bit performance vs. 32 bit, George N. White III
    • Re: C++: 64 bit performance vs. 32 bit, Patrick Schaaf
      • Re: C++: 64 bit performance vs. 32 bit, Anton Ertl
      • Re: C++: 64 bit performance vs. 32 bit, Casper H . S . Dik
      • Re: C++: 64 bit performance vs. 32 bit, Anton Ertl
      • Re: C++: 64 bit performance vs. 32 bit, Stephen Sprunk
      • Re: C++: 64 bit performance vs. 32 bit, Greg Lindahl
      • Re: C++: 64 bit performance vs. 32 bit, Anton Ertl
      • Re: C++: 64 bit performance vs. 32 bit, Stephen Sprunk
      • Re: C++: 64 bit performance vs. 32 bit, Grumble
      • Re: C++: 64 bit performance vs. 32 bit, Anton Ertl
      • Re: C++: 64 bit performance vs. 32 bit, Casper H . S . Dik
      • Re: C++: 64 bit performance vs. 32 bit, Anton Ertl
      • Re: C++: 64 bit performance vs. 32 bit, Eric Gouriou
      • Apple and 64-bit (was: C++: 64 bit performance vs. 32 bit), Anton Ertl
      • Re: Apple and 64-bit, Niels Jørgen Kruse
      • Re: C++: 64 bit performance vs. 32 bit, Seongbae Park
      • Re: C++: 64 bit performance vs. 32 bit, Casper H . S . Dik
• Re: hpux11 PA-RISC ABI Specification, Eliot Miranda
  • Re: hpux11 PA-RISC ABI Specification, Eliot Miranda
    • Re: hpux11 PA-RISC ABI Specification, Richard
  • <Possible follow-ups>
  • Re: hpux11 PA-RISC ABI Specification, sieler
  • Re: hpux11 PA-RISC ABI Specification, sieler
    • Re: hpux11 PA-RISC ABI Specification, Cary Coutant
• Re: Harvard Vs Von Neumann architecture, Dan Koren
  • Re: Harvard Vs Von Neumann architecture, David Kanter
    • Re: Harvard Vs Von Neumann architecture, rambam
  • Re: Harvard Vs Von Neumann architecture, Sander Vesik
    • Re: Harvard Vs Von Neumann architecture, Dan Koren
• Call for Papers: IAENG International Workshop on Electrical Engineering (in IMECS 2006), imecs2006
• Function calls as mini-threads?, Torben Ægidius Mogensen
  • Re: Function calls as mini-threads?, Brian Hurt
    • Re: Function calls as mini-threads?, Torben Ægidius Mogensen
      • Re: Function calls as mini-threads?, David Kanter
• Some confusion on Video Memory, zhangyue.zl@xxxxxxxxx
  • <Possible follow-ups>
  • Some confusion on Video Memory, zhangyue.zl@xxxxxxxxx
• First IBM gave up on Josephson Junctions..., John Savard
  • Re: First IBM gave up on Josephson Junctions..., Erik Magnuson
  • Re: First IBM gave up on Josephson Junctions..., Eugene Miya
    • Re: First IBM gave up on Josephson Junctions..., John Savard
• Power Consumption by Component?, Benjamin Ylvisaker
  • Re: Power Consumption by Component?, David Kanter
• Are software-visible registers needed?, Chris Barts
  • Re: Are software-visible registers needed?, Stephen Fuld
    • Re: Are software-visible registers needed?, Terje Mathisen
      • Re: Are software-visible registers needed?, Stephen Sprunk
      • Re: Are software-visible registers needed?, Terje Mathisen
      • Re: Are software-visible registers needed?, Stephen Sprunk
      • Re: Are software-visible registers needed?, Jan Vorbrüggen
      • Message not available
      • Re: Are software-visible registers needed?, toby
    • Re: Are software-visible registers needed?, Chris Barts
      • Re: Are software-visible registers needed?, John Ahlstrom
  • Re: Are software-visible registers needed?, scraig46
    • Re: Are software-visible registers needed?, John Savard
      • Re: Are software-visible registers needed?, Jan Vorbrüggen
  • Re: Are software-visible registers needed?, Torben Ægidius Mogensen
    • Re: Are software-visible registers needed?, Chris Barts
  • Re: Are software-visible registers needed?, Dan Koren
    • Re: Are software-visible registers needed?, Chris Barts
      • Re: Are software-visible registers needed?, Dan Koren
• Re: Measuring time taken by code ?, Eugene Miya
• Re: AlphaStation 200, Bob McConnell
  • Re: AlphaStation 200, Jan Vorbrüggen
    • Re: AlphaStation 200, FredK
      • Re: AlphaStation 200, toby
• Re: Disadvantages and advantages of condition code register and general-purpose register, Stefan Bieschewski
  • <Possible follow-ups>
  • Re: Disadvantages and advantages of condition code register and general-purpose register, robert . thorpe
    • Re: Disadvantages and advantages of condition code register and general-purpose register, Terje Mathisen
  • Re: Disadvantages and advantages of condition code register and general-purpose register, Iain McClatchie
    • Re: Disadvantages and advantages of condition code register and general-purpose register, David Hopwood
• Re: Return address stack, Peter
  • Re: Return address stack, robertwessel2@xxxxxxxxx
  • <Possible follow-ups>
  • Re: Return address stack, MitchAlsup
    • Re: Return address stack, Luke
• Re: 64 bit humour, mahurshi

• Security
• UNIX
• Linux
• Coding
• Usenet

• Archive
• About
• Privacy
• Search
• Imprint