2066-pin processors

Dec 20, 2018 287 Replies

Problem is that you don't have dedicated I/O and memory busses per core.

Except that the frameworks that apps are built on get more and more bloated.

Again, assuming you have enough I/O resources and pins. That's where a SOC could come in super handy.

Depends on what kind of parallellism. Doing unrelated tasks in different threads benefits from highly multicore processors. Scale-out computing such as my clusterized FDTD EM simulator needs very low latency interconnect and so benefits very much from symmetric multiprocessor (SMP) CPUs, which have enough interconnect fabric that every core can access all of memory directly.

The problem with super large SMPs is that the cache-coherence traffic scales faster than linearly with core count, so you eventually run out of gas. Nonuniform memory access (NUMA) machines don't handle as wide a range of problems well. A lot of computer design work goes into handling that little problem.

Cheers

Phil Hobbs

Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com

Damn; beat me to it :)

The most expensive processor is 4000 MIPS, has 32 cores, interrupt response latency is 10ns, and i/o is timed to occur at 4ns resolution.

What are the 8 channels used for ? I would understand one channel for code access, one for stack (local data) and one or two for general data access, but 8 ?

The 64 bit mode doesn't even support segment registers, but in 32 bit mode the 32 bit segment registers are present (but generally nit used), which would have been handy for selecting the memory channel. Apparently the channel must be specified in the page table ?

It seems that the transition has been more due to marketing needs than actual usage needs,

While writing programs in assembler, it was very handy, if the hardware supported 32 and 64 bit instructions, but these days compilers can generate code sequences for larger data types, when those are rarely used.

I used 64 bit Alphas in the 1990's and then the only practical need for 64 bits was for memory mapped files. Memory mapped files re used often for database access. Just declare a huge (say 1 TB these days) array or struct and associate it with a disk file, situated on one or more physical drives. The program performs normal assignment statements to the array or struct and the OS virtual memory mechanism performs the loading from disk and write backs as with the page file. The application never performs any explicit read or write calls, but may use some flush commands to prematurely copy back a memory page to disk to avoid loosing data if power is lost.

The memory lane propagation delay makes it impractical to make individual data reads or writes to a main memory location, instead a whole cache page is loaded at once, so the propagation delay effects the block only once, instead of each individual data access.

^^^^oxymoron^^^^

(Not you, but white chocolate.)

"Nice herrings" too.

John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com

This is a nice architecture for making pseudo"ibterrupts" consisting of

- watt for "interrupt"

- perform "interrupt" service routine

- restart code

The wait for could be waiting for an external event, such as a state change of a hardware signal. Since most cores are at any time in the wait state, it is critical that the wait doesn't consume a lot of power.

>

If the number of pins can be radically reduced by integrating the memory, it would be possible to usee DIL like constructs with pins on the sides only and stick a heat pipe under the chip.

Yes. That would be more reliable than what we have. Most would sleep most of the time. Gates are cheap.

I only have 95 running now. Even that seems like a lot.

One core per process. You can call that "massively parallel" if you want. I don't.

DEC did a good job of having the hardware protect the system. Intel did not. So we have jumbled code and data spaces, stack overflow exploits, unchecked buffer exploits, cache leaks, wild pointers, all that Intel stuff.

It should be impossible to execute data space or for a task to modify code space or for a stack to overflow without a trap or for a task to write to the boot or OS or driver images on disk. Flat impossible.

We are, basically, running 40 year old languages on 40 year old processors.

John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com

There needs to be serious hardware protection around each core. One or a few cores could run the OS and manage everything. A core could be dedicated to each i/o device or file system, again with hard protections.

Multiple cores wouldn't be as hardware efficient as sharing, but our problem now isn't hardware, it's people.

Blame whoever invented virtual memory. The Devil probably.

A good memory management scheme could allow shared memory regions with cache coherency, or maybe just don't cache shared data.

We sure don't have good memory management now.

Isn't it time for some new architectures? We have decades of accumulated horrors to learn from.

John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com

It's been through three whole caches, I don't think they much care which is used for what!

I think you basically answered your own question here,

:-)

Tim

Seven Transistor Labs, LLC Electrical Engineering Consultation and Design Website: https://www.seventransistorlabs.com/

Gosh, it's almost as if you think code isn't data. :-)

There are quite a lot of applications where that is an acceptable scheme to follow, but most (by quantity) aren't, so the computers aren't, either. ("Quantity" being what I assume the quantities are for embedded, portable and desktop computers with any kind of update or bootloader process that isn't the hardware programming port, JIT compiler or the like.)

Note that even includes a lot of ATmega CPU applications, for example, because code is readable as data (very normal, initializing registers from immediate operands or program memory directly (LPM instruction)), and code is writable from data as well (SPM instruction, flash write).

Probably a few DSP applications strictly prohibit such "shenannigans", but they must not be very useful in that case (which may be fine, special-purpose mask ROM devices). I know among early GPUs for example (Nintendo 64, SEGA Saturn, etc.), these often used a wide DSP with a small instruction RAM and therefore could be reprogrammed (or "microcoded" as the case may be) depending on what operations were desired.

Mask ROM devices are the only obvious absolute case, but even that fails (or is at least made very murky) when ROP (return oriented programming) is considered. That is, pushing a custom sequence of stack addresses, to return to a desired series of functions (including in the middle of a function, for interesting effects).

Which is the whole point of a computer. If it's Turing-complete, it doesn't matter what you think. There is a way. ;-)

Tim

Seven Transistor Labs, LLC Electrical Engineering Consultation and Design Website: https://www.seventransistorlabs.com/

is

and multiple cores, multiple processes etc.

It is more useful than that; the "select" statement allows waiting for a number of "events", and proceeds when the any one occurs.

For example, you can simultaneously wait for any of - an external input, timestamped when it occurs, or - an external output to complete at a pre-specified clock tick, or - a message from another core - a timeout

One way of thinking about it is that to a useful extent the RTOS is implemented in hardware.

The hardware and software has a pedigree going back to the 70s and 80s, and some of the concepts reappear in various processors and languages.

This is the only example where the hardware and software are very well integrated with each other.

It is for *hard* realtime embedded computing, not general purpose computing.

It may or may not be critical, but the cores do suspend until any of the pre-specified events occurs.

Code is meant to be executed; data is not [1]

Some CPUs can't tell the difference between Ispace and Dspace and stack. Some OSs don't separate code from data. I could name names.

Immediates basically move a little data from code space into a register, which I guess we can consider to be "data." But immediates are safe. Modifying code space is not.

We need absolute hardware protections, and we don't have them. So we depend on programmers for security. You know how that works out.

[1] interpreters like Python, or pseudo-machines, appear to execute from d-space, but they actually don't.
John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com

at what point does bits on a harddrive moved to ram become data or code ?

When the OS sets up the hardware memory management and then loads memory regions from files on disk. Program execution or i/o operations can then modify data space.

With gigabytes of ram, we don't really need overlays or even virtual code space any more. Something would need to be done about DLLs, but that shouldn't be difficult; they go into Ispace too.

Code goes into Ispace, data into Dspace. If the hardware recognizes them as distinct.

This used to be obvious, until Intel and Microsoft forgot.

John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com

e
l
?

so data just need to take a detour around the harddisk and it can also beco me code

8 DDR4 DIMMs
When I tried casting out nines I made a hash of it.

I will take 4096-bit computing, thank you.

Winfield Hill wrote in news: snipped-for-privacy@drn.newsguy.com:

My last one was built (by me of course)over 3 years ago. It took me over 2 years to build it. It had an i7-3930K in it though. 6 cores. It (the cpu) still sells for $595. IIRC it is an LGA2011 socket device. All told, it cost me about $2500.

I very much like, however, my Lenovo P71 mobile workstation. It was already built, and it is a Xeon with an Nvidia Quadro graphics adapter. It friggin screams and pushes 4K displays with ease. It lists for between $4500 and $7000. Mine cost me $3400 and is worth about $5000.

Phil Hobbs wrote in news: snipped-for-privacy@supernews.com:

Note that this number went down as companion chipsets were perfected and as elements were directly integrated into the main cpu.

Rent's rule is not about cpu pin counts. Is is about "logic block' pin counts AND the gate counts pinging them, and that includes support chips too.

So, yeah, the number has gone back the other way. And with all of Intel's internals and chopping up instructions etcetera to get thing done more has caused the gate to pin count to go the other way.

Way more gates per pin now that in the 4004 days.

Also, this rule does not mention a time factor, which was what I disputed.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required