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.
Intel Alder Lake vs. Apple M1
- Thread starter leman
- Start date
- Sort by reaction score
“P” does not mean “programmable” by consumers. It requires very complicated software and dedicated hardware to program an FPGA. You think consumers program EEPROMs too? They also have a “P” for programmable.
Whatever it is, x64 has it and Apple doesn’t, and therefore Apple bad.
Not everyone is a first time user. Add-on board is archaic though so prefer on-chip plus near future is speech to code.
Just waiting for “M1 bad because customers didn’t tape it out”
The good news is that in ASICs now, routing also dominates everything
You can fix slew rates with repeaters, but parasitic RC is still a pain in the ass. That was even the case back in the mid-1990’s - most of the time I spent on physical design was on manual placement, partial manual routing, shielding against coupling caps, etc.
yeah - i think this guy was thinking that the "cells" had relatively weak drivers so buffering the outputs of flops or logic gates would improve things. we had a design on tsmc40lp which definitely had that characteristic. anyway i never had to do full custom design and we usually threw everything over the wall to layout people when i was working on ASICs. CPU design is another level... i think about tredennick laying out the 68k by hand - if i understand it that was one of the last designs to be done without any real automation?
I’m not sure. When we did the powerpc x704 we had very little automation. We’d write logic equations in a modified version of C, which would automatically create a corresponding ECL or CML logic gate, but you wrote the equation in such a way that the gate was pre-determined, so it was more a translation than an automation. There was no synthesized logic or anything like that - it was all just shorthand for verilog gate logic where you are determining the transistor stack by writing it in logical form. Layout of each cell was automatic so that we could rapidly test our designs, but was replaced by hand-drawn polygons (we had a couple folks who did that full time). In the end, most of the cells that were actually used were hand drawn. We did pre-routing of many of the wires by hand, and we manually placed cells (by adding comments to the C-code, telling them where to go). So pretty much all that was automated was final routing (though we had to handhold the tools quite a bit for that - we used Cadence but tricked it into doing what we wanted). RC extraction and timing analysis was automated, but the design work was mostly done by hand. Thinks like the chips in the 70s and early 80s were done even more manually than that.
Jim Keller would say not everyone dwells on the past. Kids are now exposed very early to Raspberry Pi which can be used to program EEPROMs.
https://www.rototron.info/recover-bricked-bios-using-flashrom-on-a-raspberry-pi/
https://www.rototron.info/recover-bricked-bios-using-flashrom-on-a-raspberry-pi/
Last edited:
Not everyone dwells on the past, but you think EEPROMs are the future?
Please don’t, I want to see Mitchy have a big meltdown trying to justify why Apple Silicon is bad.
This can’t be a long troll, no one is this committed to the bit. I wanna see how far one can stretch mental gymnastics.
To catch anyone up:
The current argument is that the future is teaching children about EEPROM programming (because Jim Keller said so) which is facilitated by x64 exclusively, and therefore Apple Silicon bad.
Dropped arguments:
1. CentOS 7 compatibility
2. FPGA being the future and superior to cpu/gpu
3. Intel better because they might, maybe, theoretically are perhaps developing RISC-V
4. cmaier is not Jim Keller(?)
5. Intel will build skynet
This is honestly the best fever dream of a thread I’ve ever seen.
The current argument is that the future is teaching children about EEPROM programming (because Jim Keller said so) which is facilitated by x64 exclusively, and therefore Apple Silicon bad.
Dropped arguments:
1. CentOS 7 compatibility
2. FPGA being the future and superior to cpu/gpu
3. Intel better because they might, maybe, theoretically are perhaps developing RISC-V
4. cmaier is not Jim Keller(?)
5. Intel will build skynet
This is honestly the best fever dream of a thread I’ve ever seen.
Just wait until you see his Beanie Baby collection.
Make up your mind maybe? Weren’t you just complaining about the difficulty running a ten year old Linux kernel on modern ARM hardware?
To be fair though, CentOS 7 indeed doesn’t seem to boot
Make up your mind maybe? Weren’t you just complaining about the difficulty running a ten year old Linux kernel on modern ARM hardware?
To be fair though, CentOS 7 indeed doesn’t seem to boot
I also like “Jim Keller would say” as if he’d know. I’m the only one here who worked with the guy
Oh and I forgot one final point:
Kids have had access to things like the Commodore 64 for 30 years now (the greatest progammer who ever lived, the late Terry Davis got his start with it!) there’s still not a huge consumer demand for easily reprogrammable hardware.
Kids have had access to things like the Commodore 64 for 30 years now (the greatest progammer who ever lived, the late Terry Davis got his start with it!) there’s still not a huge consumer demand for easily reprogrammable hardware.
Ah the good old days of writing BASIC, and making fun drawings with Logo.
To be fair though, CentOS 7 indeed doesn’t seem to boot
Ask any IT engineer/sysadmin to explain what stable vs unstable means and why the former carries more weight.
...or compiling C applications on a Sinclair Spectrum which required you to run a cassette-tape to load "stdio.h" every time you compiled the simplest app..good times
Yep, been there done that on the ASIC prototyping thing. On the project where we actually needed the FPGA prototype to run at >150 MHz, I was lucky enough to work with designers who were receptive to me asking for some flops here and there. (They didn't always give them to me, of course, which is when I got to have "fun" trying extreme tricks to make Xilinx P&R do what I wanted it to.)
Can confirm that timing closure is still mostly about route delay. The one notable exception to that rule in Xilinx FPGAs is their block RAMs, which have substantial clock-to-out delays. The lookup table "gates", though, are usually a tiny fraction of any given path.
Xilinx timing closure has gotten a lot easier in the newer chips after they switched from UMC to TSMC. Don't want to imply it's about the process tech, though - it might be to some extent, but they also took it as an opportunity to fundamentally redesign their clock routing scheme, and they also seem to have realized that the ratio between routing and lookup table resources in 7 series and especially 6 series was too skewed towards LUTs. I see a lot less route congestion in Ultrascale.
you may have been hitting the snoooze button too long lately. apple has been shippping 6000 product for months .
Nope. Just means you failed to check the Mac Pro product page before posting.
p.s. We’ll see around early 2023 if there is a dead end on 3rd party GPUs. No 3rd party drivers for macOS on M-series at WWDC 2022 would be bad sign . AMD shipping 7000 series in quantity and then Pro version of cards and still no drivers on macOS Intel side would just put the Intel and M-series versions on the same page in support effort going forward .
Last edited:
In the '90s, the transition from the first PPC-capable OS (7.1.2) to the 68K EoL (8.5) took around 5 years. In '06, Apple introduced x86 machines running Tiger and EoLed PPC about 3 years later with Snow Leopard. The first x86-EoL OS could happen this or next fall (ARMv8 based Darwin has been fairly stable for nearly a decade, so there is almost no need to port any legacy code, unlike earlier transitions).
Woah, software defined silicon so like FPGA embedded CPU?
https://www.tomshardware.com/news/intel-software-defined-cpu-support-coming-to-linux-518
https://www.tomshardware.com/news/intel-software-defined-cpu-support-coming-to-linux-518
one of the comments on that site:
" Intel copying the EA business model: make a full product, then strip its features to sell separately. Instead of selling one full processor for $1000, sell one crippled processor for $1000, then demand $100 for re-enabling each feature. I know that's capitalism and market rules and all, but it sounds like dishonest money to me (EA customers agree on..."