Wait a minute… aren’t you the same guy who thinks eating only lean protein is a good idea?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Anyone else a bit skeptical about Apple silicon future?
- Thread starter dapa0s
- Start date
- Sort by reaction score
Apparently not fast enough for Apple. AMD provided strong competition but Intel was happily making chips appropriate for toaster ovens. Apple is in the picture and they're still doing that. And now AMD is joining in on the fun.
Can’t say as I’m particularly worried about the future of Apple Silicon. Switching from X86/64 wasn’t a decision that would be made lightly, and certainly not one to be made if they weren’t confident about the future of the platform.
There’s no doubt whatsoever that both Intel and AMD will make great improvements to their product roadmap over the next several years. But while they’re doing that, Apple won’t be resting on their laurels.
Ever since their first in-house designs, with the A series, Apple have pushed hard and fast every year to improve upon it. To a point where in just 7 or so years, they’ve been able to produce a platform that outperforms the Intel chips it replaces, often by quite a margin. That it does so at such low TDP as well, is quite an impressive feat.
One thing that’s for sure, Apple switching to their own design, has quite possibly accelerated the plans of the other chip companies. The winners out of all of this, regardless of the platform you choose, will be the consumers, who should get better, more powerful and much more efficient silicon in the years to come.
It’s going to be an interesting journey.
There’s no doubt whatsoever that both Intel and AMD will make great improvements to their product roadmap over the next several years. But while they’re doing that, Apple won’t be resting on their laurels.
Ever since their first in-house designs, with the A series, Apple have pushed hard and fast every year to improve upon it. To a point where in just 7 or so years, they’ve been able to produce a platform that outperforms the Intel chips it replaces, often by quite a margin. That it does so at such low TDP as well, is quite an impressive feat.
One thing that’s for sure, Apple switching to their own design, has quite possibly accelerated the plans of the other chip companies. The winners out of all of this, regardless of the platform you choose, will be the consumers, who should get better, more powerful and much more efficient silicon in the years to come.
It’s going to be an interesting journey.
this is wrong on many levels. if anything C is about “ trust the programmer” while C++ will prevent the programmer to do certain quite stupid things ?
What will C++ prevent the programmer from doing? Last I checked, you can cast anything to anything and do anything you want with pointers.
but not with references (as in aliases for the variables and point to the same memory location as a variable). But C++ will prevent other things, like strictly enforcing that all functions must be declared before they are used, you cannot implicitly assign from a void* to any other type, and so on.
We might agree on that C is a hands-on language and we can program it in whichever way we want. And C++ consists of some high-level object-oriented programming constructs that help to code high-level programs.
Thus if one can say C is easy then C++ is also easier to code.
It’s been a long time since I’ve touched C, but I remember pointers being some black magic voodoo.
In some sense C++ is easier, sure. It’s also harder, in that you need to understand classes, templates, protected variables, etc. It’s definitely easier to maintain. Not sure it’s easier to code. Haven’t really thought about it, though.
I think the crust of the initial point that "C++ is more complicated" also really just comes down to it being such a big language with so much to learn.
Bjarne Stroustrup once said:
"C will let you shoot yourself in the foot. When we write C++ in a C++ style we try to engage the safety on the gun, but if we misfire we lose the whole leg"
or something to that effect.
C++ gives you a lot of tools for structuring your code better, but if you don't engage the safety so to speak, you can shoot yourself just the same
You can use a goto in either language. You shouldn't, but you can.
I think they can be simple to anyone once they get their mind around it. That said, not always simple to get right. It can be a tad tricky to debug where things go wrong when all you know is that you don't wind up at the correct memory address after following 4 pointersThey’re really simple if you’re a CPU designer
(trauma from an edge case bug when implementing memory paging for an OS, haha. Pro tip write a bunch of 0xDEADBEEF around the addresses you want to get through. It's easy to spot in a memory overview, so you can easily compute that you're 24 bytes off of where you wanted to be or whatever)Or started out writing assembler code before using a high-level language (except Basic).They’re really simple if you’re a CPU designer
I was recently reviewing a very large amount of C code, and found multiple instances of goto.
I vomited a little bit in my mouth.
On a long-ago embedded system that had loadable modules, I made the OS print 0xDEADBEEF to the console when the divide by zero interrupt vector (on an Intel 80186 that only had real-mode) was overwritten because the developers who were writing the loadable modules kept insisting that their code was correct and my OS was brokenI think they can be simple to anyone once they get their mind around it. That said, not always simple to get right. It can be a tad tricky to debug where things go wrong when all you know is that you don't wind up at the correct memory address after following 4 pointers
. I would ask them why they printed 0xDEADBEEF to the console then. They would grumble and go find their uninitialized pointer error.Edit: I might be misremembering what int 0x00 on Intel real-mode is. I think I remember divide-by-zero but now I'm thinking it might be the weird non-maskable interrupt. I don't feel like looking it up.
I'm very impressed you could contain it that well.
*Hides face in shame that I've written a few goto lines in the past year - though admittedly for projects that would never outgrow 120 lines total - just experiments*
C is a great language. It's great for teaching young kids as you can disassemble their programs to show them what it looks like in assembler. It's also great because it's really easy to screw up so that kids get exposed to crash dumps.
Haha that's greatOn a long-ago embedded system that had loadable modules, I made the OS print 0xDEADBEEF to the console when the divide by zero interrupt vector (on an Intel 80186 that only had real-mode) was overwritten because the developers who were writing the loadable modules kept insisting that their code was correct and my OS was broken
Edit: I might be misremembering what int 0x00 on Intel real-mode is. I think I remember divide-by-zero but now I'm thinking it might be the weird non-maskable interrupt. I don't feel like looking it up.
How'd you detect when it was overwritten? Did you just regularly check that the value of something matched expectation? Did you have clock interrupts so you could regularly check? Or did you just wait on sys calls?And you were correct about 0x0 being div/0. 0x02 is the non-maskable interrupt
As far as Apple Silicon goes, remember it not only outperforms in PPW terms Intel and AMD but for years it has been the fastest mobile SOC in existence and not by a small margin. Basically since A7 what Apple has been doing is putting a desktop/laptop class SOC into phones and tablets (as opposed to the claim that with M1 they are putting phone/laptop class processors into laptops and desktops).
Haha that's great
And you were correct about 0x0 being div/0. 0x02 is the non-maskable interrupt
We used BADF00D for RAM returned by MALLOC to try to catch uninitialized memory segments.
Nvidia, which is looking to buy ARM, was built on gaming revenue and it's still a huge part of its business. If the mainstream corporate world remains closed to Apple, I think Apple also passing on AAA gaming is leaving another big slice of the market to Windows.
The 0xCAFEEBABE ate 0xDEADBEEF but it was 0xBADF00D. Fortunately, they had good 0xC0FFEE and 0xC0C0A
That's awful - real programmers use setjmp/longjmp....
OTOH, back in the good old days we didn't have them new-fangled try/catch statements, so goto does have some uses.
goto breaks the principles of structured programming and you can no longer trust the lexical structure of the program to match the execution structure. State. Dijkstra wrote about the problems with goto all the way back in 1968. As I alluded to in a prior comment I'll use goto if I'm writing some really short, temporary, experimental code and just need to test out something real quick and it's the fastest way to do to, but goto is a big "code smell"
I can see the case you're making for emulating exception behaviour with long jumps/goto but really I'd prefer a restricting that doesn't "throw" instead. Set an errno and return a null pointer or a special value that indicates an error. I'd go as far as to say I'd prefer you malloc an int and give me the pointer to it so we can make null an error number instead of returning an int directly if errors can occur. It'll effectively make it a form of "optional"
Regardless of the approach I feel like there's always a better alternative - Or at the very least almost always