|
https://www.tomshardware.com/news/ascenium-reinvent-the-cpu Ascenium Wants to Reinvent the CPU - And Kill Instruction Sets Altogether It's not a Mill rebrand, but some of this sounds pretty nonsensical to me? quote:And with deep pipelines and the specialized hardware registers and stages which make up a modern CPU's processing, Ascenium estimates that around 50% of instructions are related to the movement of data through the pipeline - instructions and moves which take up both processing time and power budget. I get a kick out of showing more software oriented folks register renaming, but someone doing this since 2005 ought to have heard of it. But "data through the pipeline" isn't quite even that. Or it's a slightly different point on the Cell curve, you've got a zillion simple FPGA slices that can be configured a few ways based on workload. Anyway, ISA's are a thing of the past, good riddance, now throw your code into the magical parallelism machine.
|
#
¿
Jul 15, 2021 16:22
|
|
|
|
| # ¿ May 14, 2024 18:17 |
|
|
Harik posted:TI MSP430: seemingly operates on unicorn farts, not electricity I designed something with a MSP430, it had a capacitive sensor. The factory reported that they would put the device into the test jig, turn the power on, and the software would report PASS before they got anywhere near the capacitive sensor. The eventual root cause was the UART lines TX/RX were providing enough juice for the chip to boot and limp through the cap sense procedure. When it got a real power supply the numbers got big enough that the SW recorded the PASS because it saw enough swing on the pads. The ISA was understandably limited. I had a few bit-shifts, but the ISA didn't have anything variable so they just had a function that was 10 of them they'd jump into at the appropriate point. Switch statements got boiled down to a jump table. An intern wrote something like (I%40) and saw it executing orders of magnitude slower because it was spending the vast majority of time doing that division.
|
|
#
¿
Jul 25, 2021 13:16
|
|
|
movax posted:I hate MSP430s. Used them in space applications (at the time, it was the 'lol FRAM is invincible logic') and ran into the same issues as above, but due to I2C. No built in CAN controller also sucked. FRAM is destructive reads, so IIRC, at least the FR5969 had a stupidly large amount of die area spent on capacitance to help not corrupt itself upon power loss. What's the smallest thing with an integrated CAN? M3 or better? When I was jobless and kinda hungry for work I asked a robot startup I'd talked with, they were having CAN gremlins and really needed that specific expertise. It sounds like a ridiculous bus, swings that would zap most stuff are the norm. PCjr sidecar posted:"The magic compiler will save us", but now with LLVM.
|
|
#
¿
Aug 10, 2021 23:32
|
|
|
the real commitment to x86 was when they sold off marvell and the x-scale ARM that was doing quite well at the time you can talk about dedicating resources to the high end, and I distinctly recall Otellini talking up "if they sell 100 smartphones, we sold a $600 server core to the backend" explanation for why getting eaten alive from below was fine and dandy, but that was the big bet in my recollection
|
|
#
¿
Oct 3, 2022 17:47
|
|
|
idk there's a more interesting question right next door, why didn't _intel_ make a successful phone chip. And they did! Had a best-in-class offering a while back. Then in 2006 they sold off the entire XScale division to Marvell. Way up at the c-level, it was a bet on "x86" in an abstract sense over continuing to build ARM cores in house.
|
|
#
¿
Jan 12, 2023 23:41
|
|
|
phongn posted:The variable length instructions of x86 make decoding more complicated than the fixed-length instructions seen on ARM. As BobHoward noted, x86 decoders are more of a bottleneck and this is one reason why. phongn posted:Unfortunately x86-64 was built to be easy to port x86 compilers over to, and so kept some of the old ugliness like variable length instructions, made relatively few named registers, etc. aarch64 instead went with a cleaner slate when they rethought ARM. how's itanium doing anyway??
|
|
#
¿
Jan 18, 2023 00:18
|
|
|
phongn posted:And yet M1 has gone wider than any x86-64 microarchitecture, and without much trouble feeding that extra-wide design? did I miss something and intel was selling fully integrated consumer electronics with the ability to pivot parts of the stack internally for free? oops! my mistake there, AMD would've been selling fully-integrated devices at a time they weren't even making their own chipsets. every way I try to approach this is fantastical phongn posted:AMD made the right decision given the market at the time, which was to make it easy for everyone to port over existing IA32 compilers. It also meant they brought in a lot of old cruft that could've been perhaps rethought. My surely obvious point was that perhaps a more aggressive ISA design could've been done, given the example of ARMv8's change from ARMv7. phongn posted:As I said, I am not arguing for a radical change like IA64, but wondering if something more than the "bolt on 64-bit to IA32" could be done, too. There is a continuum between those options. And sure, lots of ARMv8 processors are running in aarch32 mode. If anything that demonstrates that performant backwards compatibility with legacy code could be maintained while migrating to a nicer future?
|
|
#
¿
Jan 20, 2023 01:59
|
|
|
In my experience they only let HW folks design FSM's up to a certain point of complexity then they slap a 486/M3 in there and punt it all to software.
|
|
#
¿
Oct 16, 2023 19:15
|
|
|
feedmegin posted:Or even a Cortex-M0. Those things are like 1mm square these days, cheap as chips and you can do a lot with 16k of sram or whatever. Yeah, cheaper all around. Rather than a senior RTL person and reams of testing, I can slap a team together with junior HW/SW folks and curse software gremlins when it runs over.
|
|
#
¿
Oct 17, 2023 20:51
|
|
|
I'm reminded of the MIPS ISA protection where there was like... a barrel shifter instruction that was the only patented one? I'm sorta fuzzy on the details so Bob feel free to jump in here, I thought it was some Loongson ancestor where they stole the R3000 and re-implemented it apart from the shifter.
|
|
#
¿
Oct 31, 2023 22:57
|
|
|
BobHoward posted:What matters is putting together a team of talented and experienced design engineers who can make a high quality, low power, and fast implementation of any ISA. The experience part of that takes iteration (AKA practice), same as anywhere else in the world. I always think about the kind of folks who can tie specific CPU architecture features to things like how many layers the PCB needs. Sure you can distribute that decision into a team or 5, but.. I've met individual people who could do that kind of thing no sweat. In college we had an assignment that was optimizing a core, deciding where to spend transistors. 4 way 8 set iCache or spend those on the BTB. Apparently enough students complained about it that the prof took 10 minutes to explain why "design an ISA" is a bad assignment. Nobody gets to do that professionally (without decades of experience like Shippy), it's awful to grade, etc. etc.
|
|
#
¿
Dec 24, 2023 20:16
|
|
|
|
| # ¿ May 14, 2024 18:17 |
|
|
having spoken to GPU folks on that side of the divide, it's very much a cabal dedicated to knowledge that's never written down. just the same 1000 people bouncing around 4 companies
|
|
#
¿
May 7, 2024 22:43
|
|