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

Yes. C mixes up parameters, local variables, buffers, pointers, and return addresses all on the same stack. Then apparently interleaves stacks in the same address space as the subroutine code itself! There's no way to apply hardware memory-management protections to a tangled mess like that.

Run the OS in its own CPU!

John

There is nothing about the C language that requires this. C doesn't allow for returns to places other than where you were called from and the parameter stack doesn't have to contain the return addresses.

That isn't really needed with good design. In a single processor system there is only one. In a many processor system, the OS CPU can become a bottle neck. There is nothing that requires only one CPU do task switching so long as you have a "compare and store" instruction that locks. All modern processors have such a thing. Even the X86 had a lock prefix that worked on some instructions.

Right. It has occurred to me that Microsoft's compilers and linkers create such messes. Passed params and such could easily be in buffer pools (in *data* space) that are not on the stack. Of course, Microsoft would arrange for memory leaks in managing the buffers.

C is just a klugey PDP-11 assembler. In the early PDP-11 days, a lot of dangerous tricks were popular, based on abusing the 11's addressing modes. C seems to have inherited them.

The OS is always the bottleneck. But wouldn't it be nice if one CPU (out of, say, 64) ran nothing but the OS kernel?

John

Just making parameter/local space its own stack would make things a lot better. Since the x86 can do a DS:(DI+X) style addressing, the hardware could do it. It would just be a matter of compiler design.

There were mistakes in the design of C that people have gotten so used to that they now believe that it is how things are supposed to be. One of the biggies is if you declare a native type, the variable name is the value. On complex types, the variable name is a pointer. It would be better if the syntax made it clear what the nature of the variable is.

[....]

It needn't be. On one of the multitasking things I did, it accounted for under 5% of the total CPU time even when there was a lot of context switching happening.

No, it would be best if the amount of CPU power that went into the OS was exactly what was needed.

What??? Array names decay into pointers when you pass them to functions, but for everything else (including structs), any reference to a variable name in C refers strictly to its value.

Cheers

Phil Hobbs

C was designed to have a minimum number of keywords, substituting sequences of punctuation. Total crap.

Transistors, and increasingely CPUs, are free. Unreliability is still very, very expensive.

John

Umm, what's wrong with subscripts? And bounds checking?

John

... and using up one of the x86's precious registers.

Actually, whenever you use them as expressions (as opposed to lvalues), which means just about everywhere except for & and sizeof.

That's a matter of personal preference. I lean toward more punctuation and fewer words. I find that it's easier to make out the structure at a glance; words all look too alike.

Nothing stops you from doing:

#define begin { #define end }

Well, other than the fact that nothing other than the compiler will recognise your syntax.

Now, the preprocessor *was* a mistake; Ritchie has acknowledged that. If you over-use it, you end with code which you can't do anything with except compile it. E.g. auto-indenting text editors tend not to like stuff like:

#if something if (test) { #else while (test) { #endif // body }

The fundamental problem with the preprocessor is that the syntax of C source files isn't some nice neat context-free grammar, but merely a linear sequence of preprocessor tokens. The "real" language syntax only applies to what comes out of the preprocessor, which isn't much help to a text editor.

You're confusing pointers with temporaries. Temporaries are values--you can't take their addresses.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal
ElectroOptical Innovations
55 Orchard Rd
Briarcliff Manor NY 10510
845-480-2058
hobbs at electrooptical dot net
http://electrooptical.net

A = B;

If A is a void pointer and B is an integer you get the integer to pointer conversion warning. If A is a void pointer and B is a complex type, A ends up pointing to the contents of B

What do you expect from a pimped-out 4004?

John

C documentation doesn't use "temporary" as a noun. C has values and lvalues[1]. Most data types can occur as either, but arrays only exist as lvalues; in any context where a value is required, an array is represented by a pointer to its first element.

[1] And functions, which don't follow the same rules as data; you can take their address, but they aren't lvalues.

You can pass an array to sizeof to get the size of the array.

You can pass an array to & to get a pointer to the array itself. If the array has type e.g. "int a[10]" (array of 10 ints), the pointer will be "int (*)[10]" (pointer to array of 10 ints), i.e. incrementing the pointer will increment by 10 ints.

If you use an array anywhere else within an expression, the effect is as if you had explicitly used a pointer to its first element instead.

You'll need to clarify what you mean by "complex type". The C standard only uses that term in the sense of complex numbers (with real and imaginary components).

If you mean arrays, you're correct (but you could have just said "array").

If you include structures, you're incorrect:

$ cat foo.c #include int main(void) { struct foo { int x; } foo; void *p; p = foo; printf("%p\\n", p); return 0; } $ gcc -Wall foo.c foo.c: In function `main': foo.c:8: error: incompatible types in assignment

A structure will never be implicitly cast to a pointer (unless this is an extension in your particular compiler; gcc doesn't support it in any dialect).

Void pointer conversion isn't exactly vanilla programming. Unless you cast it back to pointer-to-B, that's undefined behaviour. Sort of like

*foot = bullet;

Cheers

Phil Hobbs

Pointer arithmetic doesn't change a type into a pointer.

You're moving the goal posts.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal
ElectroOptical Innovations
55 Orchard Rd
Briarcliff Manor NY 10510
845-480-2058
hobbs at electrooptical dot net
http://electrooptical.net

I assume you're referring to the complex-datatype feature that was added to C99? The original dialects of C don't have any native support for complex numbers.

Yeah, this looks a bit unfortunate. It appears to me that the C99 people chose to implement the complex types by simply re-using the array methodology... a float_Complex is represented as, and has the same requirements as a float[2] array. Hence, the normal convention for a bare reference to the name applies... in this case "foo" is equivalent to "&foo[0]" and so the name is equivalent to the address of the data.

They could, instead, have chosen to treat a float_Complex as typedef equivalent for a structure containing two floats. In this case, using the bare name in an assignment to a void pointer would have resulted in a compile error, I think, since you'd be explicitly asking to assign a structure contents into a pointer, and the structure is too large to fit.

--
Dave Platt                                    AE6EO
Friends of Jade Warrior home page:  http://www.radagast.org/jade-warrior
  I do _not_ wish to receive unsolicited commercial email, and I will
     boycott any company which has the gall to send me such ads!

WAY pimped out. Way farther so than you ever got. You saw the word 'pimped' and thought it was 'pimple' and went and got yourself 'pimpled out'.

The current offering is so far removed from the original, I am surprised when a would be intelligent person makes an inane remark based on brand loyalty, or brand denial, as in this case.