PLEX86  x86- Virtual Machine (VM) Program
 CVS  |  Mailing List  |  Download  |  Newsgroups

Thou shalt have no other gods before the ANSI C standard 1668


Your Ad Here

Your Ad Here

On Fri, 4 Feb 2005 06:14:22 +0000 (UTC) in alt.folklore.computers, "D.

intel's Vanderpool and virtualization in general 1670
almost. the 370 virtual memory architecture came out long before there was actually hardware built...

The obvious fix *now* is to use something larger than 32 bits: it wasn't obvious ten years ago.

At least 64 bit counters.

In how many programs is that actually a *requirement*? IMHO very few. Exact length types are intended for external interfaces, other types should be used within the program.

intel's Vanderpool and virtualization in general 1669
the context change is with respect to permissions, address space, registers, etc. not with respect to end resource control. this is...

Any artificial restriction is also a potential defect: unless you are dealing with a subrange, you want a type that will handle at least a certain number of bits, but you don't really care (and it could be a benefit) if it also handles a lot more.

Overspecifying the range supported also leads to defects, especially when the programmer underestimates what the program may be required to deal with. Most professionals seem to concur that the C99 intleast*t types are likely to be the most used within code, except where specific interfaces are required, or speed is a consideration.

Sure, being able to tally up 16 exabytes seems a lot now, but I can ship 100MB-s on a home GbE LAN and put 1.6TB in my current home desktop, give it five years and *drives* in the low TB will be on the desktop.

-- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

fake address use address above to reply



Your Ad Here

List | Previous | Next

intel's Vanderpool and virtualization in general 1669

Alt Folklore Computers from Newsgroups

The #1 Usenet Provider on the Internet

Thou shalt have no other gods before the ANSI C standard 1667