Thread 105749633

>A CPU with 128-bit multimedia extensions was designed by researchers in 1999.
Interesting...

not that interesting. that's the same size simd instructions have always been on every major architecture since '92.

>>105749633 (OP)
Your CPU has 512 bit instructions right now.

it's not hard to design whatever you want, the question is whether or not there's a need for it that would justify the production costs

>>105749633 (OP)
I think risc-v is the only processor that designed the core ALU out to 128 bits.
If they actually produced one, it would make it worth playing around with.

>>105751616
> would justify the production costs
Build it an they will come.
AS/400 used 128-bit addresses back to the 80s.
About 13% of the die on a typical intel desktop is actually used for general compute. The rest is for bullshit like FP and MMX and whatnot. Some of which you could ditch for faster, no setup, and no context change penalties right in the general use core.

>>105751686
You don't need 128 bits. X64 pointers are limited to 48 bits which is already 256 terabytes of memory space.

SSE is still enough for most tasks on modern CPUs.

>>105749633 (OP)
That sounds a lot like the PlayStation 2 CPU. The two VLIW vector processors and MPEG-2 decoder stood out to me, but it actually has even more similarities, like the 16 KB scratch-pad and the DMA controller for the vector processors. It also says they're for "three-dimensional geometry calculation and physical simulation" which sounds like a game console and it's what the PS2 vector processors were made for. Maybe it's a prototype version.
https://en.wikipedia.org/wiki/PlayStation_2_technical_specifications

>>105749633 (OP)
>CPU
>look inside
>ASIC
>>105753481
look at the inventor names they're all japanese. you're probably right.

we need a 1024-bit-wide CPU with a uniform address space for everything that exists in the universe

>>105751888
>64 bit cpu
>look inside
>48 bits

>>105751888
> address lines limited, remember the A20 line
That’s more to do with the specific physical memory support some bean counter decided.
There’s *no* reason why the processor can’t support it on GPRs, index, pointer and address registers.
Even a 60 year old mainframe used 24 bits of the 32 bit wide address registers, but you could use the extra bits for shit you want to do like tagging pointers.
> You don't need 128 bits
I do. So do you. Virtual memory and hash table based algorithms have been around for over a year now and are very very heavily reliant on hardware address translation.
It’s the foundation of modern (lol, for 50 years) computing. Early telephone switching systems were among the first users of that kind of hardware built into processors.

>>105751888
>tfw 512 TiB RAM
>256 TiB are unused RAM
>unused RAM is wasted RAM

>>105751888
Zfs and Ipv6 use 128 ints, those have been out for 20 years. Where’s the processor support? Nowhere.
A lot of the OS counters and perf counters need 128-bit, too, and have for years.
The more I think about it, the more ridiculous artificially staying on 64 bit sounds.

>>105758875

actually managed to allocate 256TB that is sick

>>105749633 (OP)
What if I told you that there are 20wide general core designs, but they operated at only a couple mhz?

>>105751655
rv128 isn't designed in any sense of the word. There's a section heading for it in the spec, but the section is blank.

>>105759893
you have xmm* for 128 bit arithmetic. Doing all arithmetic in 128 bit just because some things need it would be idiocy.

>>105751594
How 'bout now?

>>105753481
Yeah that abstract sounds a lot like the PS2s EE.
I see that K Kutaragi is an author. Looked up the paper and yeah all the authors are from SCEI and Toshiba.
Not that surprising to have in 1999 since Intel added MMX to x86 a few years before and SIMD wasn't exactly a new concept then as it dates to the 1970s.
PPCs VMX was far superior to x86 SIMD extensions until SSE3, which I suspect is large part of why Sony and Microsoft went with PPC for the PS3 and X360.
PS2 was crazy to program back in the day, but once we worked it out it was a very powerful system for its time. Best way to describe the difference between it and regular PC programming is that you have a bunch of buckets (memory) that are filled with firehoses (buses) instead of a big tank being filled by a faucet.

>>105761911
Yes, yes, thats what they said about 16, 32, and 64 bit basic processor word lengths when moving from 8, 16, and 32-bits respectively.

The xmm ops work like fp coprocessors, slow everything else down, usually have to shuttle the data into and out if them, don’t have all the standard operations, can’t be used as index registers, and often cause a processor context switch/escape when used, and some require extra setup overhead. It’s a pain in the ass.

Our company replaced asic with fpga, and then replaced fpga with xeon when they became fast enough, but it doesn’t use and simd shit, it’s mostly XOR operations.