Lots of people confuse learning to code in C with learning how hardware works. Its close in some ways but not all.
EDIT: WOW. I'm amazed at how many people think that C is "how memory works". Just wow. This is one of those things where you're confusing the map for the territory and ascribing value to something because its "hard". C is a fairly high level abstraction for interacting with a computer...i know that everyone has heard that c is close to being assembler...but what you are forgetting is that assembler is also an abstraction over operands. The reason i think its important to point this out is that malloc and free arent magical. Othér techniques are just as valid and the notion of "low level" is misleading. C makes tradeoffs that actually give rise to all of the vulnerabilities and stability problems in all the software that you have ever used. Those tradeoffs are REAL and just because lots of you get this macho nonsense about not using safe collection types everyone on the planet has to deal with malware. So many of you buy your own bullshit at an astonishing level...its really breathtaking to see how many of you cant see the built in assumptions in what you are saying.
At this point, the only thing that still keeps C close to the hardware is that they need to keep the hardware close to C model because of all the legacy code in the world. Most recent hardware innovations, like pipelining, speculative code execution, SIMD, etc are not easily expressed in C. Additionally, C was written in a time where accessing the memory was cheap and had a uniform cost - nowadays memory access times vary immensely depending on if its cached or not.
malloc and free aren't even a part of C itself. Other than static (globals and "static" the keyword) and automatic (stack) allocation there isn't any memory management in C itself. malloc and free are library functions wrapping system calls. That's something to do with the operating system - the machine itself has NOTHING like malloc and free.
I and many people know C but know fuck all about assembly programming. (for now)
P.S: Read "Deep C Secrets - Expert C Programming", and once you've understood the chapter on memory, go back and read the malloc implementation in the back of K & R.
malloc() and free() (not to mention realloc() and calloc()) are part of the Standard C Library, and must be provided for a C compiler to be certified as ANSI compliant. Granted, you don't have to use any Standard C Library functions, but a C compiler must have them (or else, it can't claim ANSI compliance).
I knew they were part of the standard library and the specification -- I mean, even the stdio stuff is, right? -- I had no idea the compiler had any involvement in that, though.
I know gcc provides them for you if you don't specify the right includes, but that's gcc, like.
I think I'm going to go on considering them not technically part of C itself, until I have more information.
(I'm not sure if you'll see this or not, but it's worth a shot)
Like I said, before a compiler can be certified ANSI C, it must provide the Standard C Library (for whatever platform the compiler is for). As a programmer, you don't have to use the supplied functions, but they are there, and they do comprise a part of the C Standard. And because the functions are defined, the compiler writer can do some pretty neat things.
For instance, include string.h, and that informs the compiler you want to use the string and memory functions defined by the C Standard. The compiler can then generate code directly for, say, memcpy() instead of generating a call to said function (it can inline it, even though C89 made no standard method of inlining a function). Or the function sin() if you include math.h (some CPUs support a single instruction for the sin function). Don't include string.h, and well ... what happens is up to the compiler. Most just give a warning about an undefined function, assume it's defined as "int unknownfunction()" and leave it up to the link phase to either find it or not.
Yes, there is a distinction between the C language, and the C library, but both must be provided if a C compiler wants to conform to the C Standard.
The way that C memory management works is a design decision. that design decision had criteria that informed it...it's no more or less valid than other design decisions that are made in the face of other criteria. It's no more "low level" that lot's of other methods that have been/are being used.
ufo got my point. the modern microprocessor is vastly different than the view of the world that is exposed through C. The fact that C still works is more of a testament to hardware designers than it is something "intrinsically true" about C and its design decisions.
It's really weird that people talk about phones like general purpose computers that they should be in control of...I'm just pointing out that it has NEVER been the case. I'm not even sure what it would take to get to where it could be.
With PC's there was some FCC oversight, being a device without a transmitter meant that there wasn't a whole lot though. With cell phones they are so heavily regulated...and the carrier is such an integral part of the equation. It seems like you might get more of what you want with a wifi handset or device. The carriers have no vested interest in making a handset like you describe and their monopoly status makes market pressures almost non-existent forces for change.
The guy that ran windows phone is now the head of the entire windows division. His name is Terry Myerson. I doubt very seriously that he is going to shitcan windows phone.
Sure, no problem. Windows Phone will be cancelled in 2015 after MS realizes it's been a massive failure. They'll also lay off 30,000-40,000 people in 2014. And they'll quietly sell off the device division they bought for 7 Billion dollars and take a massive loss.
I think that you missed my point. The guys that was in charge of developing Windows Phone 8 is now the guy in charge of Windows. Windows Phone won't be canceled, it and Windows will become the same thing...just with form factor differences. Same thing with XBOX OS. It's Windows. Things that make sense for the desktop won't be on the XBOX or the Phone...and vice versa. You sound like you aren't a metro fan...They do need to make sure that the desktop is still a useful tool...but here's the thing. In 5 years you will be hard pressed to find a monitor of any size or type that isn't touch enabled.
As to selling off the device division...I don't see that happening either. MS needed Nokia's supply chain, and delivery systems. They needed to have a division that knows how to take a device from the drawing board to the shelf quickly...which Nokia should be able to do now that it doesn't have to make money. It's weird, but taking a long term view with the device department just like bing and xbox gives the people in that org some room to move.
I find it crazy how much people dislike one company while another company...also a legal fiction that exists solely to make money...that company is ok. They "get" me...or "it". Like Google's PR moves like "solving death"? Seriously? They sell advertising. Meaning that they sell YOU. I"m under no illusions about MS prior behavior. I'm also under no illusions that Apple or Google are somehow different. They aren't.
@ 2Ghz they can probably produce large quantities. It sounds like they went for a "safe" fabrication process so that the initial rollout is as defect free as it can.
