Slashdot Mirror

Isn't this what EFI (Extensible Firmware Interface) is supposed to be? The specification is freely available, and there is a reference implementation released under the Common Public License (CPL). I know it is a product of Intel, but it is suppsoedly an architecture-agnostic platform.

Does anyone know why there hasn't been been more widespread adoption of EFI?

A recent example would be the Hyperthreaded CPUs. SQL Server can be licensed per CPU and with Hyperthreading, the software does for all intents and purposes treat it as a second CPU. However, Microsoft's stance is surprisingly that you only license per the physical processor.

Pretty reasonable because the second virtual processor isn't as nearly as good as having two physical processors for most server applications since the virtual processor runs only when the real processor isn't busy. For regular systems, this is most of the time, but for most multi-threaded server apps running full blast, it's very seldom.

Multi-core, on the other hand, gives multiple independent physical processors that just happen to fit into one socket. Its more than likely multi-core systems will be priced according to the number of cores.

A recent example would be the Hyperthreaded CPUs. SQL Server can be licensed per CPU and with Hyperthreading, the software does for all intents and purposes treat it as a second CPU. However, Microsoft's stance is surprisingly that you only license per the physical processor.

Pretty reasonable because the second virtual processor isn't as nearly as good as having two physical processors for most server applications since the virtual processor runs only when the real processor isn't busy. For regular systems, this is most of the time, but for most multi-threaded server apps running full blast, it's very seldom.

Multi-core, on the other hand, gives multiple independent physical processors that just happen to fit into one socket. Its more than likely multi-core systems will be priced according to the number of cores.

I decided to speculate on wasteful uses of IPv6 addresses, and run some calculations on how long it would take to expend them.

Method #126: Mote technology matures. Intel is working on them. Berkely is working on them.

Each mote gets an IPV6 address. Maybe you drop a few hundred into each automobile to test everything from tire pressure to CO2 content in exhaust. I don't think this comes close to exhausting the IPv6 addresses.

Method #127: RFID tags for consumer goods. Give each and every consumer product an IPV6 address to track it from manufacturing to purchase.

Reasonable uses of IP addresses? Maybe not. But with 2^128 addresses, it would still take a very long time to use all of the address even with blatent misuse of them.

2^128 is 10^14 moles. A chemist could give you precise estimates, but a 300 milliter can of distilled water contains about 15 mole molecules of water. So, lets say that you could put an RFID tag on every water molecule in every can of pop sold. Maybe water rationing is getting very serious. You'd still have to drink 10^13 cans of pop. Coca cola sells about 4.3 * 10^9 bottles of pop a year. We could go about 23,000 years without needing to recycle IPv6 address on the water molecules. On the one hand, if we can figure out how to attach wireless TCPIP enabled RFID tags to water molecules, we can probably upgrade our IP protocols. On the other hand, who wants to update the hardware attached to 10^14 moles of water?

These exist for several microcontrollers (HC11) and for older x86 chips but for a modern P4 system you would need to emulate the host-bridge, RAM, system timer, essentially the entire motherboard. To give you an idea of the scope of this, when Intel verified the logic of the P4 it took 1 week to simulate 6 billion cycles. This used a compute farm of several thousand P3 machines(yes, running Linux). Interesting paper about the process

I actually made an 8080 emulator that ran on an FPGA PCI card. It had a host bridge, RAM and an interface to the PCI bus. Unfortunately it ran at 400 kHz(1/12 the speed of the original) but one could change the microcode on the fly and view/modify just about any register in the design.

To this day, I still have no idea who or what was responsible for the name "Pentium," but I suppose it no longer matters. A question that's still worth asking, though, is why the Pentium name has stuck around as the brand name for Intel's main processor product line through no less than four major architectural changes.

Vladimir Pentkovski is a Principal Engineer in the Microprocessor Product Group in Folsom. He was one of the architects in the core team, which defined the Internet Streaming SIMD Extensions of IA-32 architecture. Vladimir led the development of Pentium III processor architecture and performance analysis. Previously he led the development of compilers and software and hardware support for programming languages for Elbrus multi-processor computers in Russia. Vladimir holds a Doctor of Science degree and Ph.D. degree in computer science and engineering from Russia.

Intel IA-32 Optimization Manual says that self-modifying code is not recommeded. It's bad for the branch prediction, pipeline, etc.

The problem, IMHO, is that ALL high end routers use HARDWARE routing (see: flow/fast switching in 7500/12000s) instead of software routing. Unless you 're building ASICs to handle stuff in the data plane (VIPs or whatever the 12ks use for dCEF and the like), you're not really in any danger of becoming used by the higher end routing equipment manufacturers.

However, they still run their protocols, control "plane", etc. in software on a commodity general purpose CPU, which is what the likes of XORP, GNU Zebra and Quagga cover. Indeed, the Juniper routing engines are literally PC's running some flavour of BSD off of flash. There is nothing stopping one implementing off-board forwarding cards for a PC - you just end up with Juniper's architecture. Intel for example have ASICs targeted toward the building such boards, the Intel Network Processor range, customised Xscale CPUs with PCI interfaces designed for offloading packet-forwarding.

Still, a PC is *more* than capable of replacing any low-end Cisco, eg 26xx, which btw use software forwarding, not hardware, and even mid-range, provided one is careful to match the PC hardware to the requirements.

Cisco at least notified their large carriers before specific details leaked onto the net - I shudder to think of someone posting 0day exploit code for something like this on Full-Disclosure.

There was a Cisco BGP DoS vulnerability announced recently, GNU Zebra and Quagga were not vulnerable to the DoS. Also, why do you think white hats would leak a DoS for an open project but not for IOS? Or why do you think CERT, would not co-ordinate with an open project for vulnerabilities, when they already do so?

actually, intel would be the one with strongarm tactics

Intel is Arm's strongest compeditor in low-power embedded chips with its Xscale chips.

Unless I am very much mistaken the XScale is based on the ARM instruction set.

So Intel isn't competing against ARM with the XScale as they pay ARM to use the design.

Rather than making it suck, Intel have produced a higher clock rate version of the architecture for use in applications that need more oomph.

See: Intel PXA255 Processor with Intel XScale Technology

I don't see what the big deal is here.

The big deal is making it easy for Joe User to do it every day without thinking. I should remind you that Joe User is no scripting wizard.

Intel's Digital Briefcase will be realized with the introduction of the following technologies:

1) High-density, low-power, nonvolatile memory
2) Integrated logic & wireless

At this point, the Personal Server becomes feasible. A specification for "personal server compliant" operating systems helps any compliant PC in the world "log on to you", as they say in Soviet Russia. All of your preferences down to the last minute detail (wallpaper, favorites, browsing history, etc) will immediately be transferred to this particular PC and it will be as if it were your own.

This is close. Since Microsoft will try to "embrace and extend" this to the point that we can't use these devices without Windows, the open-source community will need to rapidly develop this into an open, robust standard that will work with all PCs. I give it two years... Power consumption will be the biggest issue. Otherwise, you could stick a WiFi link on an iPod and do it now (though I suppose it could be done with a cable that also supplies power).

Of Intel's 13 chip manufacturing plants, 6 of them are outside the United States. There's even one in Israel:
Intel's worldwide manufacturing operations.

Details of locations of Intel-chip factories

How many fabs does intel have and where are they located?

Either you're lying, or Intel is. Why? From the "Features and Benifits" page of Intels' _Linux_ C++ compiler:

"Source and object code compatible with GNU C to preserve code integrity and development investment. Intel® C++ Compiler conforms to the C++ ABI and is source and object compatible with gcc version 3.2."

Now, have you tested Intel's compiler and have demonstrable proof that it doesn't comile with Linux software? Or the kernel? Or are you just BSing because you think GCC sucks (which it does for pure performance, but it does run on a LOT more platforms than Intel's compiler).

All the modern x86 CPUs I know of have bugs. It's a matter of how serious they are and whether you can fix them without a recall.

See: Prescott bugs
Itanium bugs
Opteron bugs

Just do a search of errata and the cpu you're interested in.

Most people won't encounter these bugs because the CPU makers would have tested the CPUs on a superset of what most people do. And nowadays most people don't write new code and of the code that people write, most of it is actually written by compilers, so genuinely novel machine code could be quite rare.

Thus it would be pretty poor QA to release something with a bug that prevents _boot_up_ in a significant percentage of cases. While most people may not do some rare computer operation followed by some weird stuff that doesn't do anything really useful 99.999% of the time, most people do have to _boot_ their PCs at least once in a while.

Maybe the issue did not show up on Intel's reference boards and only shows up on some 3rd party boards. If it actually showed up on Intel's boards then it is a very bad sign.

So far Intel and AMD's x86 CPUs have been pretty OK in my experience. Sun's UltraSPARC IIs were/are crap tho - 2nd lev cache probs.

All the modern x86 CPUs I know of have bugs. It's a matter of how serious they are and whether you can fix them without a recall.

See: Prescott bugs
Itanium bugs
Opteron bugs

Just do a search of errata and the cpu you're interested in.

Most people won't encounter these bugs because the CPU makers would have tested the CPUs on a superset of what most people do. And nowadays most people don't write new code and of the code that people write, most of it is actually written by compilers, so genuinely novel machine code could be quite rare.

Thus it would be pretty poor QA to release something with a bug that prevents _boot_up_ in a significant percentage of cases. While most people may not do some rare computer operation followed by some weird stuff that doesn't do anything really useful 99.999% of the time, most people do have to _boot_ their PCs at least once in a while.

Maybe the issue did not show up on Intel's reference boards and only shows up on some 3rd party boards. If it actually showed up on Intel's boards then it is a very bad sign.

So far Intel and AMD's x86 CPUs have been pretty OK in my experience. Sun's UltraSPARC IIs were/are crap tho - 2nd lev cache probs.

ICH6 = Intel I/o Controller Hub 6. Basically it is the south bridge for Intel's new chipset.

ICH6 = Intel I/o Controller Hub 6. Basically it is the south bridge for Intel's new chipset.

I've been researching chipsets for digital TV. Here are my links to current hardware products:

STMicroelectronics System on Chip (2) Get Linux here
ATI Xilleon 220 (Products)
Sigma Designs Digital Media Processors (Products)
IBM PowerPC405 STBxx (Zarlink [2], Araneo)
Texas Instruments DM642 DSP (i3 Mood Box , X-Designs Flikit + Softier MediaLinux)
NEC EMMArchitecture2 (Galaxis + LinuxTV , PRISMIQ + Linux)
Equator Technologies BSP-15 boards
Via CN400 (Mini-ITX Board), PM800 and PM880 (w/ HDTV for Pentium 4) , ShowShifter HMN, Soyo Multimedia Ready Motherboard (with TV Tuner, $129.99)
Toshiba TX System RISC (MontaVista Linux)
Windows chipsets:
Intel 815 VisionPlus terrestrial box (Korean OEM)
AMD Geode (CoCom)
ARM (Samsung, etc.)
Digeo X-Stream (Paul Allen company)

check this out

and this

At least 5 of the top 10 systems are running Linux, starting at number two with Thunder at the Lawrence Livermore National Laboratory. The others are IBM BlueGene/L clusters at places #4 and #8, Tungsten at NCSA at #5, MPP2 at Pacific Northwest National Laboratory at #9, and probably also the Dawning 4000A at the Shanghai Supercomputer Center as #10, though I'm not 100% sure about this last one.

Yeah because we all know that Fortran is completely dead.

oops: profile guided optimization works for compiled languages too :)

microsoft visual c++ 2005
intel c++ 8.0
intel fortran 8.0

oops: profile guided optimization works for compiled languages too :)

microsoft visual c++ 2005
intel c++ 8.0
intel fortran 8.0

I want a handheld computer that is also quick with 3d.

I'd really like to see competent graphic chipsets worth a damn become a standard feature in these devices.

Do I have to get a PSP? But I'd like to play around creating 3d apps of my own - do I need to get a Sony SDK license (at what cost)? This one, at $2800, still sports the (for 3d) underpowered 855GM chipset. Shared memory, no 3d hardware (or does it have?)...

Ok, with a 3d gfx card, the battery life might fall through the roof - but still... I'd feel like Superman without the cape with a hi-res screen like that, a fast CPU, but with abysmal overall 3d performance.

The big savings is in having a decent UI and time not spent messing with the computer to get it to work right. I value my time and my hearing (the Mac is pretty silent).

I guess Macs aren't for everyone. If you must build your own, then don't get a Mac. But, don't compare a Mac against a home built (not saying you are, but it seems to be a trend).

Moores law is doubling of transistors, not clock speed. This is an easy way to keep up, double the core, double the transistors.
http://www.intel.com/research/silicon/mooreslaw.ht m

Another reason that SCSI drives perform better in RAID arrays is that SCSI permits out-of-order I/O request execution.

It also has great command queuing as part of the out of ourder command execution. Serial ATA supports Native Command Queuing, providing these features plus First Party DMA and Interrupt Aggregation. Hardware support is relatively new. Seagate was the first to make a drive that supported it. My understanding is that the majority of Serial ATA drives out there essentially have parallel IDE controllers with a Serial ATA converter.

Here is a great article from Intel on NCQ: PDF HTML.

IDE performs blocking I/O, so everything would have to wait until drive 3's read was complete. I don't know if this also applies to SATA.

Interrupt Aggregation and First Party DMA were designed to limit the effects of this. SCSI still has an advantage with its offloading controller though. I also understand that the maximum queue depth for commands on the SATA is 32, while it is 256 for SCSI.

That is not Moore's law. Don't misuse the term.

That is not Moore's law. Don't misuse the term.

An earlier poster mentioned how such a skill can help you find compiler bugs. This can be the case, but it is rare; I have located two such bugs in 20 years of programming. A more common use is to locate bugs in your code. When your brain refuses to see the missing braces around the wrongly indented code, or an spurious semicolon at the end of an if or while statement, reading the generated assembly code can save some extra hours of frustration. You will be able to see that the code the compiler generates differs from the code you think you wrote, and this will point you to the bug's location.

As I argue in Code Reading, other cases where reading assembly code can be of use are:

• to understand how an implementation-defined operation (e.g. a type cast) is actually performed,
• to see how compiler optimizations affect the resulting code,
• to verify that hardware-specific code written in C/C++ actually performs the operations you expect, and
• to learn how a particular construct can be written in symbolic code.

To read compiler-generated assembly code you need:

• An understanding of the processor's architecture: registers, instruction format, addressing modes. See for example Intel's Pentium Architecture Manual.
• A handbook of the processor's instruction set. Again, see for example Intel's Pentium Instruction Set Reference Manual A-M and Intel's Pentium Instruction Set Reference Manual N-Z.
• An appreciation of how compilers generate code for modern structured languages. The key ideas here are the stack as a way to handle nested function and method calls, the frame pointer as a way to access function arguments and local variables, and the virtual function table often used for implementing dynamic dispatch in OO languages. The Red Dragon Book is the venerable classic here.
• A way to obtain an assembly code listing of your high-level language code. The Unix compiler's -S switch, and the Java SDK "javap -c" command are two methods I often use. In gdb you can use the disassemble, nexti, and stepi commands to examine your program at the level of discrete processor instructions.

Obligatory "hello, world" program written in i386 assembly:

hello: .string "hello, world\n"
.globl main
main:
pushl $13
pushl $hello
pushl $1
call write
addl $12, %esp
xorl %eax, %eax
ret

Diomidis Spinellis - #include "/dev/tty"

An earlier poster mentioned how such a skill can help you find compiler bugs. This can be the case, but it is rare; I have located two such bugs in 20 years of programming. A more common use is to locate bugs in your code. When your brain refuses to see the missing braces around the wrongly indented code, or an spurious semicolon at the end of an if or while statement, reading the generated assembly code can save some extra hours of frustration. You will be able to see that the code the compiler generates differs from the code you think you wrote, and this will point you to the bug's location.

As I argue in Code Reading, other cases where reading assembly code can be of use are:

• to understand how an implementation-defined operation (e.g. a type cast) is actually performed,
• to see how compiler optimizations affect the resulting code,
• to verify that hardware-specific code written in C/C++ actually performs the operations you expect, and
• to learn how a particular construct can be written in symbolic code.

To read compiler-generated assembly code you need:

• An understanding of the processor's architecture: registers, instruction format, addressing modes. See for example Intel's Pentium Architecture Manual.
• A handbook of the processor's instruction set. Again, see for example Intel's Pentium Instruction Set Reference Manual A-M and Intel's Pentium Instruction Set Reference Manual N-Z.
• An appreciation of how compilers generate code for modern structured languages. The key ideas here are the stack as a way to handle nested function and method calls, the frame pointer as a way to access function arguments and local variables, and the virtual function table often used for implementing dynamic dispatch in OO languages. The Red Dragon Book is the venerable classic here.
• A way to obtain an assembly code listing of your high-level language code. The Unix compiler's -S switch, and the Java SDK "javap -c" command are two methods I often use. In gdb you can use the disassemble, nexti, and stepi commands to examine your program at the level of discrete processor instructions.

Obligatory "hello, world" program written in i386 assembly:

hello: .string "hello, world\n"
.globl main
main:
pushl $13
pushl $hello
pushl $1
call write
addl $12, %esp
xorl %eax, %eax
ret

Diomidis Spinellis - #include "/dev/tty"

An earlier poster mentioned how such a skill can help you find compiler bugs. This can be the case, but it is rare; I have located two such bugs in 20 years of programming. A more common use is to locate bugs in your code. When your brain refuses to see the missing braces around the wrongly indented code, or an spurious semicolon at the end of an if or while statement, reading the generated assembly code can save some extra hours of frustration. You will be able to see that the code the compiler generates differs from the code you think you wrote, and this will point you to the bug's location.

As I argue in Code Reading, other cases where reading assembly code can be of use are:

• to understand how an implementation-defined operation (e.g. a type cast) is actually performed,
• to see how compiler optimizations affect the resulting code,
• to verify that hardware-specific code written in C/C++ actually performs the operations you expect, and
• to learn how a particular construct can be written in symbolic code.

To read compiler-generated assembly code you need:

• An understanding of the processor's architecture: registers, instruction format, addressing modes. See for example Intel's Pentium Architecture Manual.
• A handbook of the processor's instruction set. Again, see for example Intel's Pentium Instruction Set Reference Manual A-M and Intel's Pentium Instruction Set Reference Manual N-Z.
• An appreciation of how compilers generate code for modern structured languages. The key ideas here are the stack as a way to handle nested function and method calls, the frame pointer as a way to access function arguments and local variables, and the virtual function table often used for implementing dynamic dispatch in OO languages. The Red Dragon Book is the venerable classic here.
• A way to obtain an assembly code listing of your high-level language code. The Unix compiler's -S switch, and the Java SDK "javap -c" command are two methods I often use. In gdb you can use the disassemble, nexti, and stepi commands to examine your program at the level of discrete processor instructions.

Obligatory "hello, world" program written in i386 assembly:

hello: .string "hello, world\n"
.globl main
main:
pushl $13
pushl $hello
pushl $1
call write
addl $12, %esp
xorl %eax, %eax
ret

Diomidis Spinellis - #include "/dev/tty"

Here they are.

Or you may prefer AMD-64, here.

Right, but that's called the Pentium-M, not Centrino; unless you've seen the name used officially outside complete laptops with integrated WiFi.. :)

Looking at Intel's Centrino page seems to confirm this; it's a "range of technologies", including Intel's wireless networking hardware, motherboard chipset and the Pentium-M. Hence it's not a processor family, it's a mobile technology family, which includes a processor family name most people will at least partly recognise.

But anyway, </pedantic> :)

Actually it would seem that RAID is the only disk advantage. Hitachi is one of the SATA manufacturers that use the Marvel bridge to convert parallel ATA signals to serial, and the bridge can only communicate as fast as the controller allows, so it's probably back to ATA-133. If you look at Intel's info, it's more likely Ultra ATA 100 (PDF). (ATA Bridge) Native SATA throughout, controller and drives, is almost as expensive as SCSI; smart buying with this in mind are likely to benefit you if you discover you need that throughput to burn these monsters.

They are actually not that bad an idea IF implemented properly. It is a fact of tech support that some hapless user will lock themselves out of their own box.

I think the best solution I've seen is from Intel for their 530T/535T series switches, where you can download a software utility that will generate a default password for your switch when you enter in the MAC address of the switch's management module. This password ONLY works from the console (requiring physical access to the switch, or root access to a console sharing device attatched to it).

I was thinking that if they upped this to also be time dependant, it would increase the security even more, but this is wrong for two reasons - a) if the switch is hosed, there's no telling what time it thinks it is, and b) anyone capable of generating a password the first time would be able to generate it again a second time for another x minute "safety window".

Of course, this begs the question - what is the difference between using a tool like this and just not requiring a password when logging in from the console?

Dont flash cards have a maximum number of write operations? Or is that USB keys?

All FLASH devices have a limited number of write cycles. Looking at the specs for a random device shows that modern devices support over 100,000 write cycles, and I think this is per sector.

A good device driver will use various techniques, such a wear leveling, to extend the life of the device.

BTX is intended to replace ATX. With the new form factor the CPU is placed closer to the front intake fan for better cooling of the CPU & RAM.

BTX info

I googled for intel warranty retail and found the Intel(R) Processors - Warranty Information Q/A

I'm sure we all remember Intel's legal troubles with AMD over the use of the term "486".

Essentially, the judge ruled that a number could not be copyrighted.

Additionally he ruled that a number that "made sense" (such as DX/2 for a 2x multiplier chip) could not be copyrighted either, which is why the DX4 was only 3x multiplier.

Intel has some thoughts on the topic.

Namely, the usual suspects like non-condensing humidity, temperature levels, and so on are things to consider.

Additionally, you can look at your monitor's specs to see what kind of viewing angles it will support.

Sponsored by Intel Corporation, I run one of the Grand Challenge teams, Team Overbot. We have a vehicle (a modified six wheel drive Polaris Ranger), a shop in Redwood City, funding, equipment, and people. We're well along; the vehicle has most of its actuators and some of the sensors working, and about a third of the software is running. We're one of the five DARPA-accepted teams.

Many of us are Stanford alumni or students, but this is not a Stanford project.

Our basic technical approach is to build a rugged, reliable vehicle with conservative control strategies. Others may be faster, but we expect they'll get into trouble at high speed. Our top speed is 40MPH. The real problem with the Grand Challenge is not going fast on the easy parts; it's getting through the hard parts.

The 6WD chassis we're using is one of the most bump-tolerant platforms around. It can go over railroad ties at top speed without problems and without going airborne. The center of gravity is low. The front and mid axles have independent suspension; the rear axle is a swing arm. This simplifies low-level vehicle control. All wheels can be driven, although at higher speeds, we will switch from 6WD to 4WD.

We have five computers on board. Three are small PC/104 machines, and two are Pentium 4 machines. All run QNX (the OS for when it has to work.) All are industrial-strength ruggedized units. The actuators are all servomotors driven by industrial microcontrollers. All this hardware is off-the-shelf industrial control gear.

Sensors include LIDAR, doppler RADAR, sonars, cameras, INS, GPS, etc. Some of them are used in unusual ways. That's all I'll say about that.

The pathfinding strategy is indeed borrowed from video game technology. It's more structured than Brooks-type behavior based robotics, and it's less structured than Latoumbe-type planning. There are three layers of control; the top one we call the "back seat driver", because it has only advisory authority over the "driver".

We have road map and topo data onboard, but it's used more as a hint than as rigid guidance. We take the waypoints DARPA gives us (on a CD, at 0430 hrs the morning of the race) and load it in. There's no offline preplanning. Wouldn't help in the real world.

If nobody wins this year, which is quite likely, we'll be back next year with a faster vehicle.

Post questions and I'll answer them here.

John Fagogle
Team Fuckbot

BTW, here's the manual if you don't believe me. Section 3.2.3, Multi-segment Model. Scroll down to Section 3.4.3.1 to see the table of types.

Yes, they do. Why does everyone insist that they don't? I was reading about the execute vs. data segments back in the days of 386s!

Here's the manual if you don't believe me.

I saw another, older paper that Intel has done on this, for maximizing developer efficiency: Here it is

Intel has been doing some outsourcing to India that has reflected very positively upon the American economy and marketplace, and created hundreds of new jobs, with more to come. According to this press release, the global awareness and insight into other markets gained through outsourcing has really helped to streamline the organization and effectivize work in the US markets.

AGP3.0 allows a core-logic implementation to provide multiple AGP3.0 Ports. Each AGP3.0 Port is a bridge device with multiple AGP3.0 devices hanging off the secondary bus. Each Port has a separate Graphics AGP aperture and GART that is independent and not shared with another AGP3.0 Port; however, these are shared across the devices within a single AGP3.0 Port.