Slashdot Mirror

Modern processors have some ram for microcode updates

http://www.enlight.ru/docs/cpu/INFO/mcupdate.htm

I think with this and with clever hacks in the OS, you can fix most bugs. So probably there's a lot of person to person communication between processor manufacturers, Bios writers and OS vendors and the net result is that it all seems like it works. Of course if you're an obnoxious vendor of a not too commercially important OS, you're probably excluded from this, which is why Theo is upset.

All operating systems at the time quickly implemented a workaround for the bug.

Wikipedia link
More than you ever wanted to know about the F00F bug

F0 0F C7 C8

Oh... you wanted a recent one...

Obligitary karma whoring informative link: The Intel Pentium F00F Bug @ x86.org.

(It's kinda interesting, I was just reading about that bug earlier today.)

The TIS Committee grants you a non-exclusive, worldwide, royalty-free license to use the information disclosed in this Specification to make your software TIS-compliant; no other license, express or implied, is granted or intended hereby.

You can usually tell by running the cache prefech algorithm at http://www.x86.org/secrets/prefetchqueue.htm. If modified to use some privliged instruction, reinterpreters will either (1) crash, (2) give a prefix size of 1, (3) give a rediculous size, or (4) run way too slow as it has to recompile the code because it is self-modifying in the inner loop.

~:( It's not FOOF bug, it's F00F bug. Those are ZEROES between the F's.

http://www.x86.org/errata/dec97/f00fbug.htm

Below is part of the README file that comes together with a BIOS upgrade of D875PBZ Intel motherboard. If you read carefully Intel is fixing errors on the CPU itself ("CPU patches"). Some of these patches were loaded during runtime by the OS, namely Windows. Now it appears to be loaded by the BIOS. Intel does have a way to patch instructions and microcode inside it's CPU. I know that IBM also does that with it's Power series of CPU, at least P4 and P5. Maybe the chinese guy figure out how to undo the P4 to celeron changes (just guessing).
Does anybody knows how these patches are loaded on the CPU? This site http://www.x86.org/ used to have a lot of little known Intel info, however it haven't being updated in a while.

--------------
DATE: March 31, 2005
PRODUCT: Bonanza Standard BIOS
P34-0125 (P34, build 0125)
About This Release:
  March 31, 2005
  BZ87510A.86A.0125.P34.0503312215
  UNDI 4.1.16
  CPU Patches: M04F2001, M04F2101, M04F2308, M04F241E, M04F252B, M04F2737,
M04F292E, M0DF320A, M0DF330B, M1DF3414, M9DF4112
--------------

Regarding crap loads of cash, see:

http://www.sacpcug.org/archives/9904/kk0499.html
How much cash did Intel spread out to promote this claim I wonder.
On the positive side, Intel claims PSN technology will help keep stolen credit cards from being used on-line, aid in discouraging CPU counterfeiters, and enhance some computer services.

The inverse is a conclusion intended I believe to promote the idea that AMD non PSN chips will some how facilitate stolen credit cards being used on-line, aid in encouraging CPU counterfeiters, and de-enhance some computer services.

I believe AMD had to conclude that the message was we have more money to spend on propaganda than you do. Add the PSN and this wont become an issue.

More cash was certainly offered to AMD by way of the FTC "Deal"

FTC reaches antitrust deal with Intel

By Dan Goodin and Sandeep Junnarkar

March 8, 1999
C/Net
Lawyers for Intel and the Federal Trade Commission have reached a tentative agreement to settle the government's antitrust case against the world's largest computer chipmaker.

The company and the FTC's filed a joint motion to delay start of the antitrust trial so that commissioners can vote on an 11-hour settlement the two parties reached over the weekend. The trial, which was to start tomorrow, is stayed indefinitely while the agency's four active commissioners consider the proposed settlement, which litigators on both sides signed yesterday.

Details of settlement talks emerging

By Michael Kanellos and Dan Goodin

March 8, 1999
C/Net
The witnesses in the FTC-Intel case were the last to know about the surprise settlement, details of which began to emerge this afternoon.

The terms have not yet been made public and lawyers on both sides would not comment on them. But one source familiar with the settlement said that in the general terms of the agreement, Intel will agree not to use access to its chips or product information as a lever to settle intellectual property claims. In other words, companies will be able to pursue legal actions against Intel without necessarily running the risk of finding itself with no chips.

Intel's on line legal Bio from:
http://www.x86.org/news/1999/news030899.htm
It still rolls me back to see Intel's lies about the PSN laid out so clearly yet they are still defended as innocents.

Now EU Intel offices are raided, AMD is not knee jerk reacting, but closing the book legally with I might add with a perceived a moral superiority over Intel.

Cell is a normal PPC chip with 8 SIMDs. Last time I checked, MMX didn't revolutionize PC chips. Being MMX is Simd instructions for pentiums. Cell is nothing new, they just call the simds,a Synergistic Processor Unit. Gotta love marketing speak.

True. Whatever it is, if VIIV is supposed to stand for 64, then it looks like Intel's history of math bugs has extended beyond the chips and into marketing.

Wow, just like a Pentium II!

This directed at SCO: RTFA!
(TIS specification doc for ELF)

Remember the TIS comittee? Probably not, as SCO never was part of it. Santa Cruz Operation (oldSCO) was, however, as well was Novell.

Page 2, paragraph 1:
The TIS Committee grants you a non-exclusive, worldwide, royalty-free license to use the information disclosed in this Specification to make your software TIS-compliant; no other license, express or implied, is granted or intended hereby.

Loadall acually set the entire cpu state from a memory structure, but it couldn't exit protected mode. The only way to exit protected mode on a 286 without a machine reset was to force a triple fault, which would reset the cpu but not the entire machine. http://www.x86.org/productivity/triplefault.htm

Call me stupid, but AFAIK x86 chips have full segmentation support (in protected mode obviously) - ability to define different segment types (read only, r/w, execute only, etc)... For those of you not familiar with it, it allows the programmer to define different types of memory segments, which would allow you to do some pretty interesting things such as defining read-only code segments (so the machine instructions can't be modified in memory), and non-executing data segments (to prevent OS from trying to run code stored in program data/buffers). This would solve the problem, at least how they addressed it in the article.

If current operating systems actually used this in addition to paging (which is what most of them only use now), why would they need to create a new chip? Linux does not fully utilize segmention, mostly only paging. I don't have any resources on MS OS design right now so I can't comment on it... (although maybe looking at the recent source would help some ;)

No, the REAL issue is memory space. 32 bit just won't cut it anymore for large database servers and the like, regardless of the movement for clustering.

Every intel chip since the PPRO can handle 64gb of ram

A website that could come in handy for learning about x86 assembly language is DDJ Microprocessor Center. In specific, the On-line Intel Documentation links are almost invaluable when learning to code for the x86 architecture. Being Intel reference manuals, they tend to cut to the case relativly quickly.

A website that could come in handy for learning about x86 assembly language is DDJ Microprocessor Center. In specific, the On-line Intel Documentation links are almost invaluable when learning to code for the x86 architecture. Being Intel reference manuals, they tend to cut to the case relativly quickly.

A PII clocked at the same speed as a PPro was slower (remember how www.x86.org got in trouble for publishing those benchmarks? ) was hotter than a PPro, etc... then people realised that PIIs were becoming eventually faster and cheaper than PPros, and PPros got phased-out (I think retired early by Intel to force people to buy PIIs is closer to reality).

Conclusion? Don't buy the latest and greatest processors in their early incarnation because besides the hype, they don't run that much faster than the previous generation... but eventually will.

---

There's not enough space inthis little box for a diatribe, so here's a few links for x86 assembly language programming:-

www.hugi.de Windows based (linux ver on its way) assembly diskmag with plenty of articles on the advantages and disadvantages of ASM vs HLL

www.x86.org loads of info about x86 programming

www.cfxweb.net Loads of articles on assembly programming and HLL too.

Hope that clears a few things up *g*

Intel Bugs - The Errata series

At the same time, the founder of x86.org had a major problem . He basically reconstructed the secret "Appendix H" technical references for the 586. He simply analyzed the data that Intel published and filled in the blanks. Intel harassed him and sued him for breaching NDA's that he had never agreed to in the first place!

I attribute much of AMD's success to the incredible uproar over these issues right around the time that AMD was releasing its newest chips. Definitely some of Intel's biggest legal blunders.

Does anyone notice that all of the mistakes they listed are relatively recent events? I mean, sure five years ago in computer history is a long time, but this is a company that's been around for thirty years. Surely, they've made bigger mistakes than these.

And I'm sure I'll get flamed for this, but here's a pretty good website on the x86.

--

Or here's the assembly source.

--

Or here's the assembly source.

--

The only 36bit thing about the PPro's is that it has 36bits of virtual address space, ie. 64Gb. Apart from that the CPU still has 8-, 16-, 32-, 64-, and some steppings have 128-bit instructions on them.

Then there's the issue of bus size - I'm not clued up at the moment as to the bus sizes of the different CPU's, but there you have another factor.

How how do you rate a CPU in "bits", I ask you? Cut the flames then, until you know what you are saying.

For my $0.02 on the topic, let me go through a bit of history:

8086: 20 bits of virtual RAM address space (thank you Bill Gates), giving 1Mb maximum RAM. 8bit and 16bit instructions, with an 8bit memory bus. Debut at 4.77Mhz

80286: Here is the first example in the x86 range of trying to maintain backwards ISA compatibility. The '286 had a 24bits of address space (16Mb) but in order to maintain compatibilty with a handful of 8086 programs, the designers did two very annoying things:
1) The A20 address line: without setting this stupid control line, the first 64kb of each 1Mb of RAM (excluding the first 1Mb) is inaccessible. Crazy! Just because some software on the XT relies on the fact that there will never be over 1Mb of RAM, and sometimes write to addresses higher than 1Mb knowing that the effective address would wrap around back to 0....
2) 80286 Real Mode: The CPU still started up in "Real Mode" which prevents you from using any of the extended RAM you may have...you had to clumsily switch to 16 protected mode (a programmer's nightmare) to access the RAM. I wont go into the topic of Intel+M$+undocumented instructions right here.

80386: This was a huge jump up from the '286, with 32bits of virtual address space (4Gb), a whole new set of 32bit instructions, some extra registers and a whole different architecture. This CPU would have been *great* to start with, but for the good old "ISA backwards compatibility" issues Hannibal speaks of. It introduced 32bit Protected Mode, allowing multi-tasking and hardware task switching, etc, but it *still* booted into Real Mode. What a pain in the ass. And it would take programmers *years* before they begain to come to grips with the complications of switching between these CPU modes.

Ok, "So what's the point of all this useless information?" you ask...Well, it serves to illustrate the cumbersome and incredibly annoying way that the x86 CPU's of today operate: so much red tape to go through to get to the CPU's real power, because by default it limits you to good old 8086 days.....IMHO Intel should have phased out their old way of doing things and started afresh with the 386 - trust me, applications would have been a whole lot more stable and advanced if it wasn't for the *really* silly backward compatibility issues. And besides it would not have been terribly hard to create a "virtual machine" for the old 8086 software anyway...

So, x86, it's been real. Rest In Peace. And bring on the new stuff.

Linux users aren't the only people affected by the tactics of the MPAA!

What about the people who buy a DVD for the home theatre and want to make a VHS copy for the bedroom? DVDs in Europe often have fewer features than North American DVDs. Try telling the enthusiast who owns many imported CDs that he can't import DVDs. Hell, what will people think if they were to be informed of the outright price fixing that's going on with region coding? People detest restrictions placed on them, even if they're not seriously affected. Intel caught hell from its customers over the Pentium bug, even though the bug itself didn't cause any serious problems for anybody. What people were angry about was Intel's response (Read this). In the DVD case, there are real effects of the MPAA's schemes. Anybody from set-top box users to computer users could potentially be affected.

The business practices we're fighting affect the entire damn DVD customer base. Not just Linux users (might I point out that I'm not one of them, yet I still am vocal on the matter). I don't care how much of a difference it makes, I'm casting my vote.

So tell me, how far will they have to go before they lose your patronage?

• X86.ORG
  
• Tom's Hardware
  

Exactly - that's what I said "a bit premature".

Granted, they have the slow migration path, but Intel is going to be in direct competition with them, which means that it'll be hard for them to convince developers to use their platform.

Personally, I hope they do well; it's about time Intel had some serious competition.

--

Interestingly enough, Intel owns the rights to the letter 'i' when used in lower-case for computer-related things. Actually, Intel owns patents to all kinds of wierd things (including names for unreleased processors we can suppose).

X86.ORG at one time had a full list of them ... but I am unable to find them now.

usual gritty Intel detail site - now w/ Dr. Dobbs

Chuck

First the crap with the 486DX/SX/487 being the exact same chip, then some other stuff,and now this. Intel is just like microsoft, except their stuff works most of the time. Their processors are bloat, their business tactics are, at times, very dishonorable. I'm running a dual celeron 300a system at 450MHz. And it works great because it's a fast core that's sold cheap to compete with AMD. I spent a lot of money on a dual slot motherboard, and I'm sure intel got a nice chunk of that. A lot of the people who work at intel are really nice, but if you go high up enough, some of those people are complete dicks. I hope the athlon makes them a little more humble.

Also, if you look at their patent, it reveals a lot more than it claims. It looks a lot like an attempt to place some techniques they are using somewhere where the average dozy patent official can find it, so they don't have to fight groundless patents later.

Erik Corry without his cookies (and without a Lynx accidental submit this time!)

Also, if you look at their patent, it reveals a

Personally, I don't see how IA-64 has any market. For several years it will remain over-priced for the workstation market. So, that leaves it "targetting" a server market. But given Intel history, can we truely trust them with our terra-byte databases and other critical *server* operations. Well... lets see the history and then decide:

Intel reliablity example 1) Pentium 60-90 is released:

Intel Marketing: The Pentium has a FPU that is up to 10 times faster than the i486 (notice, FPU is a key feature at this point!)

Reality: i486 correctly calculates FPU, Pentium does not. Anyone can make a random number generator that outperforms the i486 FPU

Intel Responce: Error only occurs in 12th decimal place and hence is not important. No CPU is 100% error free and this error would only occur once in a million years by the average computer user. For those that it is important to, a software fix is possible, the speed difference caused by the software fix should not be a problem for the user (Pentium FPU importance and speed is downplayed by Intel)

Internet FAQ responce: A simple division problem can reproduce the bug with errors occuring in the *9th* decimal place

IBM responce: FPU's handling of subtraction/addition can create the situation where the bug is reproduced in the next division step. A speadsheet user will run into the bug on average of once a *day*. IBM will discontinue it's pentium lines until Intel fixes the problem.

Intel reliabilty example 2) EIDE pre-fetch and Intel's motherboards with PC-Tech EIDE chipset and "Intel Inside" quality assurance

Intel Marketing: computers performance should become much faster because of Intel's push to support pre-fetch capablity in EIDE controllers and OS developers should take advantage of this feature whenever possible with no exception (pre-fetch is a key feature!)

Intel to MicroSoft: the PC-Tech EIDE chipset has a known bug which will corrupt the data with pre-fetch is enabled. When Windows '95 detects this chipset it should disable pre-fetch

Intel's "secret bug" effects on OS/2 & Linux users: data corruption occurs when Intel motherboards with the PC-Tech chipset and two hard drives. The problem is impossible to diagnose until PowerQuest discovers the bug Intel was already aware of and releases information on it. OS/2 and Linux patches appear shortly after the PQ announcement. These patches increase reliablity and hurt performance by disabling the buggy pre-fetch implimented on the PC-Tech EIDE chipset

Intel's responce: pre-fetch does not have that much of a performance gain (complette contradiction to previous Intel documentation) and disabling the pre-fetch should have no noticable impact. Since the offical (non-beta) version of Windows '95 does this fix for the PC-Tech chipset since the beginning, this bug is a non-issue

Moral of story: "Intel inside" quality assurence on their motherboards only assures reliabilty of drivers for MicroSoft Operating Systems. It provides no quality assurence of the system performance or reliablity following Intel's "documentation"

Intel reliablity example 3) F00F bug

Intel marketing: the Pentium architechure is a huge improvement over i486 and is Intel's workstation and *server* quality CPU (server capablity is a key feature)

Reality: the CPU fails to meet Intel's own documented specs to throw an exception to F00F and instead halts allowing a method of implimenting a denial of service attack either accidently or purposily against the "server" quality cpu

Intel responce: the problem should never occur in actual code and should it occur then it only requires the user to turn off and back on the machine hence this is not really a problem (The key feature of server quality is clearly downplayed here. How often do the users even have direct access to a server to restart it?)

So, is IA-64 another Intel reliablity example? According to Intel (no CPU is 100% error free), yes, it is another example that "Intel Inside" is a *warning label* that Intel "quality" assurance has been provided. History has shown that the only quality that Intel assures is that what Intel marketting considers key features WILL NOT operate as documented and Intel is prepaired to downplay the importance of the key feature.

So, IA-64 will be priced to target the "server" market. But in it's first three years of production will it be as *documented* and provide the same *quality*, reliablity, and *work-around free* performance that proven 64 bits systems do (such as IBM RS/6000, UltraSparc CPU and clones, Compaq/DEC Alpha)? History has spoken, has it not?

Oh. And I think my question still stands. Where is the REST of the IA-64 documentation (that IA-64 will fail to follow)? :-)

Personally, I don't see how IA-64 has any market. For several years it will remain over-priced for the workstation market. So, that leaves it "targetting" a server market. But given Intel history, can we truely trust them with our terra-byte databases and other critical *server* operations. Well... lets see the history and then decide:

Intel reliablity example 1) Pentium 60-90 is released:

Intel Marketing: The Pentium has a FPU that is up to 10 times faster than the i486 (notice, FPU is a key feature at this point!)

Reality: i486 correctly calculates FPU, Pentium does not. Anyone can make a random number generator that outperforms the i486 FPU

Intel Responce: Error only occurs in 12th decimal place and hence is not important. No CPU is 100% error free and this error would only occur once in a million years by the average computer user. For those that it is important to, a software fix is possible, the speed difference caused by the software fix should not be a problem for the user (Pentium FPU importance and speed is downplayed by Intel)

Internet FAQ responce: A simple division problem can reproduce the bug with errors occuring in the *9th* decimal place

IBM responce: FPU's handling of subtraction/addition can create the situation where the bug is reproduced in the next division step. A speadsheet user will run into the bug on average of once a *day*. IBM will discontinue it's pentium lines until Intel fixes the problem.

Intel reliabilty example 2) EIDE pre-fetch and Intel's motherboards with PC-Tech EIDE chipset and "Intel Inside" quality assurance

Intel Marketing: computers performance should become much faster because of Intel's push to support pre-fetch capablity in EIDE controllers and OS developers should take advantage of this feature whenever possible with no exception (pre-fetch is a key feature!)

Intel to MicroSoft: the PC-Tech EIDE chipset has a known bug which will corrupt the data with pre-fetch is enabled. When Windows '95 detects this chipset it should disable pre-fetch

Intel's "secret bug" effects on OS/2 & Linux users: data corruption occurs when Intel motherboards with the PC-Tech chipset and two hard drives. The problem is impossible to diagnose until PowerQuest discovers the bug Intel was already aware of and releases information on it. OS/2 and Linux patches appear shortly after the PQ announcement. These patches increase reliablity and hurt performance by disabling the buggy pre-fetch implimented on the PC-Tech EIDE chipset

Intel's responce: pre-fetch does not have that much of a performance gain (complette contradiction to previous Intel documentation) and disabling the pre-fetch should have no noticable impact. Since the offical (non-beta) version of Windows '95 does this fix for the PC-Tech chipset since the beginning, this bug is a non-issue

Moral of story: "Intel inside" quality assurence on their motherboards only assures reliabilty of drivers for MicroSoft Operating Systems. It provides no quality assurence of the system performance or reliablity following Intel's "documentation"

Intel reliablity example 3) F00F bug

Intel marketing: the Pentium architechure is a huge improvement over i486 and is Intel's workstation and *server* quality CPU (server capablity is a key feature)

Reality: the CPU fails to meet Intel's own documented specs to throw an exception to F00F and instead halts allowing a method of implimenting a denial of service attack either accidently or purposily against the "server" quality cpu

Intel responce: the problem should never occur in actual code and should it occur then it only requires the user to turn off and back on the machine hence this is not really a problem (The key feature of server quality is clearly downplayed here. How often do the users even have direct access to a server to restart it?)

So, is IA-64 another Intel reliablity example? According to Intel (no CPU is 100% error free), yes, it is another example that "Intel Inside" is a *warning label* that Intel "quality" assurance has been provided. History has shown that the only quality that Intel assures is that what Intel marketting considers key features WILL NOT operate as documented and Intel is prepaired to downplay the importance of the key feature.

So, IA-64 will be priced to target the "server" market. But in it's first three years of production will it be as *documented* and provide the same *quality*, reliablity, and *work-around free* performance that proven 64 bits systems do (such as IBM RS/6000, UltraSparc CPU and clones, Compaq/DEC Alpha)? History has spoken, has it not?

Oh. And I think my question still stands. Where is the REST of the IA-64 documentation (that IA-64 will fail to follow)? :-)

Personally, I don't see how IA-64 has any market. For several years it will remain over-priced for the workstation market. So, that leaves it "targetting" a server market. But given Intel history, can we truely trust them with our terra-byte databases and other critical *server* operations. Well... lets see the history and then decide:

Intel reliablity example 1) Pentium 60-90 is released:

Intel Marketing: The Pentium has a FPU that is up to 10 times faster than the i486 (notice, FPU is a key feature at this point!)

Reality: i486 correctly calculates FPU, Pentium does not. Anyone can make a random number generator that outperforms the i486 FPU

Intel Responce: Error only occurs in 12th decimal place and hence is not important. No CPU is 100% error free and this error would only occur once in a million years by the average computer user. For those that it is important to, a software fix is possible, the speed difference caused by the software fix should not be a problem for the user (Pentium FPU importance and speed is downplayed by Intel)

Internet FAQ responce: A simple division problem can reproduce the bug with errors occuring in the *9th* decimal place

IBM responce: FPU's handling of subtraction/addition can create the situation where the bug is reproduced in the next division step. A speadsheet user will run into the bug on average of once a *day*. IBM will discontinue it's pentium lines until Intel fixes the problem.

Intel reliabilty example 2) EIDE pre-fetch and Intel's motherboards with PC-Tech EIDE chipset and "Intel Inside" quality assurance

Intel Marketing: computers performance should become much faster because of Intel's push to support pre-fetch capablity in EIDE controllers and OS developers should take advantage of this feature whenever possible with no exception (pre-fetch is a key feature!)

Intel to MicroSoft: the PC-Tech EIDE chipset has a known bug which will corrupt the data with pre-fetch is enabled. When Windows '95 detects this chipset it should disable pre-fetch

Intel's "secret bug" effects on OS/2 & Linux users: data corruption occurs when Intel motherboards with the PC-Tech chipset and two hard drives. The problem is impossible to diagnose until PowerQuest discovers the bug Intel was already aware of and releases information on it. OS/2 and Linux patches appear shortly after the PQ announcement. These patches increase reliablity and hurt performance by disabling the buggy pre-fetch implimented on the PC-Tech EIDE chipset

Intel's responce: pre-fetch does not have that much of a performance gain (complette contradiction to previous Intel documentation) and disabling the pre-fetch should have no noticable impact. Since the offical (non-beta) version of Windows '95 does this fix for the PC-Tech chipset since the beginning, this bug is a non-issue

Moral of story: "Intel inside" quality assurence on their motherboards only assures reliabilty of drivers for MicroSoft Operating Systems. It provides no quality assurence of the system performance or reliablity following Intel's "documentation"

Intel reliablity example 3) F00F bug

Intel marketing: the Pentium architechure is a huge improvement over i486 and is Intel's workstation and *server* quality CPU (server capablity is a key feature)

Reality: the CPU fails to meet Intel's own documented specs to throw an exception to F00F and instead halts allowing a method of implimenting a denial of service attack either accidently or purposily against the "server" quality cpu

Intel responce: the problem should never occur in actual code and should it occur then it only requires the user to turn off and back on the machine hence this is not really a problem (The key feature of server quality is clearly downplayed here. How often do the users even have direct access to a server to restart it?)

So, is IA-64 another Intel reliablity example? According to Intel (no CPU is 100% error free), yes, it is another example that "Intel Inside" is a *warning label* that Intel "quality" assurance has been provided. History has shown that the only quality that Intel assures is that what Intel marketting considers key features WILL NOT operate as documented and Intel is prepaired to downplay the importance of the key feature.

So, IA-64 will be priced to target the "server" market. But in it's first three years of production will it be as *documented* and provide the same *quality*, reliablity, and *work-around free* performance that proven 64 bits systems do (such as IBM RS/6000, UltraSparc CPU and clones, Compaq/DEC Alpha)? History has spoken, has it not?

Oh. And I think my question still stands. Where is the REST of the IA-64 documentation (that IA-64 will fail to follow)? :-)