Re: Overview Of New Intel Core i7(Nehalem) Processor

A good start would be to keep executables and data far, far away from one another. If hardware protection (write protected, execute-only code pages, can't-execute data pages) isn't available to keep code from being clobbered, at least arranging them in the right order would help a lot: code first, static data next, dynamic data and buffers last. Something like that. A few simple runtime checks could then keep memcpy type stuff from stepping on code.

Why can't Microsoft manage this, when DEC did thirty years ago?

And embedded-system blunders like this are insane:

John

There is no reason that the logical address has to be the same as the physical address. Address translation maps the two.

All they have to be is in different pages (with proper access controls). Where they are in physical memory is irrelevant.

The common stack is still a problem.

Indeed.

On 80286-based PCs, you could control whether real-mode addresses wrapped at 1M or continued up to FFFF0 + 0FFFF = 10FFEF = 1M+64K-16. The extra

64K-16 bytes was the HMA (high memory area).

The 286 itself didn't wrap addresses; the wrapping was performed by external circutry which was added for 8086 software which relied upon addresses wrapping at 1M.

The 8088 and 8086 only had 20 address lines, so you couldn't use more than

1M without bank switching (EMS).

This "suggest you read up ..." schtick is older than usenet.

I initially thought you might be suggesting I wasn't aware of the ability to choose registers via the "mod r/m" byte, but I'm wondering if you misread what I wrote and assume that I don't know that registers can't always be chosen.

In any case, you only have 8 registers; SP is already taken, BP is taken if you want to be able to debug the code (or use enter and leave; although they're slower than using separate instructions, they take up less space, which can sometimes be important).

If you want to use another register for a separate data stack, that's yet another register which has to be saved and restored if you want to use it for your own purposes, which leaves you with just 5 registers which can be trashed at will.

There clearly is an issue with the shortage of registers on x86, otherwise you wouldn't see speed-critical code regularly using -fomit-frame-pointer.

Passing arguments on the stack is part of the ABI; it isn't something the compiler has any choice over if it wants to generate code which runs on a given OS.

Buffer overflows don't trash *code*, they trash return addresses (or, less often, data). This can be used as a mechanism to execute code, but you still have to put that code somewhere it can be executed, and the number of systems where that includes the heap and stack is diminishing.

Also, you can mitigate return address corruption with canary-based techniques (StackGuard, ProPolice, etc) and/or address randomisation.

To jump within a page is no problem. To jump to a different page, you had to write into a latch the upper bits of the address of the target. The memory is a bit blurry but IIRC, some logic parallel loaded the counter when a jump happened.

Yes, it was common to have a bunch of addresses at the high end of the page so that indirect jumps could use them.

You are thinking of external circuits. The 8088 could only address 1M with 32 bits worth of registers. This means that an 8051 can access more external RAM with out external latches etc than an 8088. It was also faster too but that is another story :)

name

to

=46rom your description it is more closely a union between a struct and an array. With some case specific useful type semantics.

lot

addressing

used

name

It

reference to

complex

like

Check this:

6.2.5 Types 1 The meaning of a value stored in an object or returned by a function is determined by the type of the expression used to access it. (An identifier declared to be an object is the simplest such expression; the type is specified in the declaration of the identifier.) Types are partitioned into object types (types that fully describe objects), function types (types that describe functions), and incomplete types (types that describe objects but lack information needed to determine their sizes). 2 An object declared as type _Bool is large enough to store the values 0 and 1. 3 An object declared as type char is large enough to store any member of the basic execution character set. If a member of the basic execution character set is stored in a char object, its value is guaranteed to be nonnegative. If any other character is stored in a char object, the resulting value is implementation-defined but shall be within the range of values that can be represented in that type. 4 There are five standard signed integer types, designated as signed char, short int, int, long int, and long long int. (These and other types may be designated in several additional ways, as described in 6.7.2.) There may also be implementation-defined extended signed integer types.28) The standard and extended signed integer types are collectively called signed integer types.29) 5 An object declared as type signed char occupies the same amount of storage as a ??plain?? char object. A ??plain?? int object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header ). 6 For each of the signed integer types, there is a corresponding (but different) unsigned integer type (designated with the keyword unsigned) that uses the same amount of storage (including sign information) and has the same alignment requirements. The type _Bool and the unsigned integer types that correspond to the standard signed integer types are the standard unsigned integer types. The unsigned integer types that correspond to the extended signed integer types are the extended unsigned integer types. The standard and extended unsigned integer types are collectively called unsigned integer types.30) 28) Implementation-defined keywords shall have the form of an identifier reserved for any use as described in 7.1.3. 29) Therefore, any statement in this Standard about signed integer types also applies to the extended signed integer types. 30) Therefore, any statement in this Standard about unsigned integer types also applies to the extended unsigned integer types. =A76.2.5 Language 33 ISO/IEC 9899:TC3 Committee Draft ? Septermber 7, 2007 WG14/N1256 7 The standard signed integer types and standard unsigned integer types are collectively called the standard integer types, the extended signed integer types and extended unsigned integer types are collectively called the extended integer types. 8 For any two integer types with the same signedness and different integer conversion rank (see 6.3.1.1), the range of values of the type with smaller integer conversion rank is a subrange of the values of the other type. 9 The range of nonnegative values of a signed integer type is a subrange of the corresponding unsigned integer type, and the representation of the same value in each type is the same.31) A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type. 10 There are three real floating types, designated as float, double, and long double.32) The set of values of the type float is a subset of the set of values of the type double; the set of values of the type double is a subset of the set of values of the type long double. 11 There are three complex types, designated as float _Complex, double _Complex, and long double _Complex.33) The real floating and complex types are collectively called the floating types. 12 For each floating type there is a corresponding real type, which is always a real floating type. For real floating types, it is the same type. For complex types, it is the type given by deleting the keyword _Complex from the type name. 13 Each complex type has the same representation and alignment requirements as an array type containing exactly two elements of the corresponding real type; the first element is equal to the real part, and the second element to the imaginary part, of the complex number. 14 The type char, the signed and unsigned integer types, and the floating types are collectively called the basic types. Even if the implementation defines two or more basic types to have the same representation, they are nevertheless different types.34) 31) The same representation and alignment requirements are meant to imply interchangeability as arguments to functions, return values from functions, and members of unions. 32) See ??future language directions?? (6.11.1). 33) A specification for imaginary types is in informative annex G. 34) An implementation may define new keywords that provide alternative ways to designate a basic (or any other) type; this does not violate the requirement that all basic types be different. Implementation-defined keywords shall have the form of an identifier reserved for any use as described in 7.1.3. 34 Language =A76.2.5 WG14/N1256 Committee Draft ? Septermber 7, 2007 ISO/IEC 9899:TC3 15 The three types char, signed char, and unsigned char are collectively called the character types. The implementation shall define char to have the same range, representation, and behavior as either signed char or unsigned char.35) 16 An enumeration comprises a set of named integer constant values. Each distinct enumeration constitutes a different enumerated type. 17 The type char, the signed and unsigned integer types, and the enumerated types are collectively called integer types. The integer and real floating types are collectively called real types. 18 Integer and floating types are collectively called arithmetic types. Each arithmetic type belongs to one type domain: the real type domain comprises the real types, the complex type domain comprises the complex types. 19 The void type comprises an empty set of values; it is an incomplete type that cannot be completed. 20 Any number of derived types can be constructed from the object, function, and incomplete types, as follows: ? An array type describes a contiguously allocated nonempty set of objects with a particular member object type, called the element type.36) Array types are characterized by their element type and by the number of elements in the array. An array type is said to be derived from its element type, and if its element type is T, the array type is sometimes called ??array of T??. The construction of an array type from an element type is called ??array type derivation??. ? A structure type describes a sequentially allocated nonempty set of member objects (and, in certain circumstances, an incomplete array), each of which has an optionally specified name and possibly distinct type. ? A union type describes an overlapping nonempty set of member objects, each of which has an optionally specified name and possibly distinct type. ? A function type describes a function with specified return type. A function type is characterized by its return type and the number and types of its parameters. A function type is said to be derived from its return type, and if its return type is T, the function type is sometimes called ??function returning T??. The construction of a function type from a return type is called ??function type derivation??. 35) CHAR_MIN, defined in , will have one of the values 0 or SCHAR_MIN, and this can be used to distinguish the two options. Irrespective of the choice made, char is a separate type from the other two and is not compatible with either. 36) Since object types do not include incomplete types, an array of incomplete type cannot be constructed. =A76.2.5 Language 35 ISO/IEC 9899:TC3 Committee Draft ? Septermber 7, 2007 WG14/N1256 ? Apointer type may be derived from a function type, an object type, or an incomplete type, called the referenced type. A pointer type describes an object whose value provides a reference to an entity of the referenced type. A pointer type derived from the referenced type T is sometimes called ??pointer to T??. The construction of a pointer type from a referenced type is called ??pointer type derivation??. These methods of constructing derived types can be applied recursively. 21 Arithmetic types and pointer types are collectively called scalar types. Array and structure types are collectively called aggregate types.37) 22 An array type of unknown size is an incomplete type. It is completed, for an identifier of that type, by specifying the size in a later declaration (with internal or external linkage). A structure or union type of unknown content (as described in 6.7.2.3) is an incomplete type. It is completed, for all declarations of that type, by declaring the same structure or union tag with its defining content later in the same scope. 23 A type has known constant size if the type is not incomplete and is not a variable length array type. 24 Array, function, and pointer types are collectively called derived declarator types. A declarator type derivation from a type T is the construction of a derived declarator type from T by the application of an array-type, a function-type, or a pointer-type derivation to T. 25 A type is characterized by its type category, which is either the outermost derivation of a derived type (as noted above in the construction of derived types), or the type itself if the type consists of no derived types. 26 Any type so far mentioned is an unqualified type. Each unqualified type has several qualified versions of its type,38) corresponding to the combinations of one, two, or all three of the const, volatile, and restrict qualifiers. The qualified or unqualified versions of a type are distinct types that belong to the same type category and have the same representation and alignment requirements.39) A derived type is not qualified by the qualifiers (if any) of the type from which it is derived. 27 A pointer to void shall have the same representation and alignment requirements as a pointer to a character type.39) Similarly, pointers to qualified or unqualified versions of compatible types shall have the same representation and alignment requirements. All 37) Note that aggregate type does not include union type because an object with union type can only contain one member at a time. 38) See 6.7.3 regarding qualified array and function types. 39) The same representation and alignment requirements are meant to imply interchangeability as arguments to functions, return values from functions, and members of unions. 36 Language =A76.2.5 WG14/N1256 Committee Draft ? Septermber 7, 2007 ISO/IEC 9899:TC3 pointers to structure types shall have the same representation and alignment requirements as each other. All pointers to union types shall have the same representation and alignment requirements as each other. Pointers to other types need not have the same representation or alignment requirements. 28 EXAMPLE 1 The type designated as ??float *?? has type ??pointer to float??. Its type category is pointer, not a floating type. The const-qualified version of this type is designated as ??float * const?? whereas the type designated as ??const float *?? is not a qualified type ? its type is ??pointer to constqualified float?? and is a pointer to a qualified type. 29 EXAMPLE 2 The type designated as ??struct tag (*[5])(float)?? has type ??array of pointer to function returning struct tag??. The array has length five and the function has a single parameter of type float. Its type category is array. =46orward references: compatible type and composite type (6.2.7), declarations (6.7).

The 8051, with its 8-bit data width, 12MHz clock, and serial ALU (12-24 clocks per instruction), was faster than an 8088? On what planet was this?

ings a

ing, the

r design.

t

On this very planet. Look up an old 8088 data sheet and you will see. With every memory operation needing a trip through the ALU, all of the speed advantage of the parallel bus was lost.

And Norton Anti-Virus.

We live in the Dark Ages of computing.

John

This is a vain attempt to solve the non-technical problem by technical means. If somebody breaks into the houses, this is not because the doors are too weak.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

On a sunny day (Mon, 15 Jun 2009 14:32:48 -0500) it happened Vladimir Vassilevsky wrote in :

Exactly! We need [law] enforcement.

Cheers! Rich

Apart from the problems with that approach, a buffer overflow doesn't have to be caused by malice. It's not that hard to pass too much data by accident; if that happens, an error message is preferable to having the application trash its memory and crash.

Just like seat belts and air bags and guard rails are a vain attempt to solve the non-technical problem of bad drivers.

John

things a

addressing, the

design.

straight

How many address bits (and pins) does your 8051 have?