snipped-for-privacy@gmail.com wrote in news: snipped-for-privacy@googlegroups.com:
The dies are attached viathermal and electrical conductive epoxy. That can lid is as close to the gates as you will get. We already sink heat from those/these packages with liquid interface and the thin thermal paste between that interface is negligible.
We already have that performance at a very good level.
A direct wash over the die with a high latent heat liquid would not yield much more. Besides that is only one chip out of an entire set.
The solution is to place the entire motherboard into a liquid bath at a very low temperature. That solution is called "Flourinert". It looks like water but remains liquid well below zero C.
Sure, if your requirements are modest, that's okay. But an Atom isn't exactly your high performance processor, and is probably a lot smaller than 20 mm square. Server processors are normally 100W+.
Remember that damaging the solder balls is a function of peak dissipation, not average.
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
So, if you want to multiply 2* pi * R, clearly R is data; how about 2? Or pi? Are they part of the code, or are they data? They're in the executable...
Your isolation scheme is likely to be as obtrusive as seven-castes-need-seven- bathrooms, and its 'security' is less certain than cost and complexity. Windows and Intel don't seem headed for page protection of that sort. You might like VMS, though.
That's true of SDRAM (and to a lesser extent to EDO) but DRAM means random-access. I presume, by cache, you mean fast SRAM? There's flash and FRAM that already complicate this quite a lot (and Intel's memory architecture path for future SSDs is more arcane yet).
The usual Intel bashing. Vax, Alpha, 68K , Fairchild Clipper, Z8K, NatSemi 32032 and others were slow, simplistic toys without speculative execution and with short pipelines that still could be understood by real people. Yet the Vax 750 and 780 were said to be bug-compatible, the later 68Ks were able to produce endless chains of exceptions thanks to their feature-ism (style = double memory-indirect for several data pieces, with lots of exceptions (protection, paging, stack overflow, arithmetic exceptions)) so instructions might take forever. No wonder that Moto gave up.
A new clean CPU is easy. The 68K and the Clipper were made by some
5 people each. We did a stack machine as a group of a few students in HP's dynamic n-MOS process. You now, precharge-logic-pre... with multiphase clocks. Spice on a CDC Cyber 7600 etc.
The problems start when you have to support it for > 20 years and are expected to deliver twice the computation power every 2 years.
OMG. In my old-ish logic analyser there is a HP King Cobra workstation RISC CPU under Unix. Slooooow as molasse. That used to be really good, then.
And that some of the new attacks work both on Intel, AMD and ARM is an indication that the problem is less on the CPU than on the system design side.
No, they are not. Couple load immediate with a computed goto/Jump .+reg and you can do all the nasty stuff. Just use the immediates as opcodes for your homebrew soft CPU. Weird storage format and inefficient for real work, but we only want to be destructive.
Yes, then we can write a loader that does not load any more.
"The death of God left the angels in an uncomfortable situation."
Comment in the VAX11 operating system, when the root process dies. (from my bio memory)
Actually they do. BTDT. UCSD p-code interpreter for the Z8000. It is not efficient to decode a p-code stream or threaded code if your only access to anything remotely readable in code space is load immediate. It is much easier to use the data segment. And the victim OS could not even tell if you are running a hidden p-code machine.
I also tried Andrew Tannenbaum's Z80 Free University Compiler Kit (sic!) but then there appeared Turbo Pascal and that was it. I have seen Tannenbaum live in guest lectures at TU Berlin and was mighty impressed. I was really thinking about going to Amsterdam.
th lots of photons & accept losses through many gates? Can you not convert to electrickery & amplify on occasion, bearing in mind that a few gates can run far faster than a whole current CPU of gates?
Optical has multiple issues, and 'many gates' is impossible without separat ion sizes of multiple light-wavelengths (i.e. you can't miniaturize it because light waves are bi gger than electron waves). Best use of optical is in peripheral processing of the lens-equals-2D-Fouri er-transform sort.
On Saturday, 22 December 2018 23:00:08 UTC, Lasse Langwadt Christensen wro te:
be
on
or
t
e
. If correct, that's only 6x the power density of the solar panel. Whether the temp rise could be kept within acceptable limits by a waterfall of nonc onductive liquid over the face of the die I don't know. Something less corr osive than water.
Still a little warm for my liking. Maybe it could double as a Nernst lamp : )
If correct, that's only 6x the power density of the solar panel. Whether th e temp rise could be kept within acceptable limits by a waterfall of noncon ductive liquid over the face of the die I don't know. Something less corros ive than water.
If you want serious heat transfer rates, look at heat pipes.
The water (or other evaporating fluid) boils off the hot bits, flows as vap our to the heat dissipating areas, and gets wicked back to the hot bit.
The fact that film boiling soaks up heat like nothing else was first discov ered in steam generating plants, where it allowed very compact boilers to g enerate lots of stream to drive the turbines.
The application to heat pipes came later.
It's a closed system (and since non-condensible gases wreck the flow rate b ack to the condensing end it has to be hermitically closed).
Phil Hobbs would have to worry about helium diffusing in ...
Most compilers produce a data section that includes constants and, usually, a lot of un-initialized (zero) variables. One old practical joke in IBM Fortran was to slip a couple cards into someone's deck that said
A=3
2=A
so the expression B= 5*2
would then evaluate as 15. The value of "2" was changed.
That's a good reason to put constants into a read-only page.
(String variables are different and messy.)
I'm an advocate for simplicity and security. We don't have those now.
Intel and Microsoft have added some rudimentary protections that basically nobody uses.
You can random access a modern DDR DRAM, but that's not efficient. To get speed, transfer blocks in bursts and cache.
That's the way it's usually done.
There have been many enticing stabs at fast 0-transistor nonvolatile SRAM (ovonics, memristors , nanotubes, xpoint, things like that) and probably some day one of them might work. Gigabytes of dense fast low-power SRAM would help us change architectures.
--
John Larkin Highland Technology, Inc trk
jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com
In transatlantic fiber communication laser pumped optical erbium amplifiers are used to compensate for the fiber losses every few hundred kilometers.
Couldn't these (especially the EDWA variant) be used for compensating gate losses as well ?
In long range fiber optic communication DWDM is used, in which up to
80 separate wavelengths are used in a single fiber, each carrying up to 100 Gbit/s each (8 Tbit/s/s total) and a single erbium amplifier handles all wavelengths. Controlling the pumping laser it should be possible to control static routing of terabit of data "busses".
For most compilers and most modern OS's, you have a number of sections for code and data, with certain attributes enforced by the OS and cpu/mmu :
.code = code section, readable and executable but not writeable .bss = zero-initialised data, readable and writeable but not executable .data = initialised data, readable and writeable but not executable .rodata = read-only data, readable but not writeable or executable .stack = stack, readable and writeable but not executable .heap = dynamic data heap, readable and writeable but not executable
Obviously it is possible to write to the code and rodata sections while programs are loaded or initialised, but the running code itself cannot change these.
And there are other sections for additional features such as stack unwind and exception handling tables, small data sections for some processors, debug sections, etc.
But it is a /long/ time since it has been normal for the OS and memory attributes to allow self-modifying code, executable code on the stack, etc.
Yes, fun tricks like that existed. This one stopped pretty much at the same time as punched cards went out of fashion. (Other things, such as executable stacks, lasted far longer - and were very much a source of security problems.)
Agreed. That is why constants /are/ in read-only pages. (There are other benefits too, such as sharing the pages if the same code or constants are used by multiple processes.)
No, they are fine as read-only data.
There is no doubt that security can always be better. Simplicity is not, however, the answer. It can often be difficult to find a good balance between security and usability - and generally if you think the answer is "simply do this" or "simply disallow that", you sacrifice too much usability in the name of security. That will lead people to find workarounds, and you are back to insecure again. (For example, people get so used to turning off Windows anti-virus software before installing programs that they will do so before installing malware.)
Somewhat incorrect. Intel (and all x86 cpus) have quite extensive protection systems, that are used by Linux and BSD (include MacOS) - and to a reasonable extent by modern Windows. Certainly Windows has been slow to use them compared to other OS's, and certainly Microsoft has shown an extraordinarily poor understanding of security - but that is not Intel's fault, and it does not apply to other systems on Intel processors. And to be fair on Microsoft, they have got gradually better in some ways.
There is a little mixup here. "DRAM" means "Dynamic Random Access Memory" - the name /does/ mean "random access". That applies to all RAM, whether it is synchronous (SDRAM) or not (like very old DRAM chips). RAM is "random access" as distinct from old sequential memory technologies such as mercury delay lines.
The DRAM cells themselves are randomly accessible - but the machinery around them works in large lumps (pages). That is because reading and writing the cells is a little slow for what you want - so pages of perhaps 4Kbits are read into a bank of very fast cache SRAM inside the DRAM chip, and this memory is used for transfer back and forth on the memory bus to the CPU or memory controller.
So everyone is right here - it's just a question of viewpoint.
There are already non-volatile DIMMs. The non-volatile cells are still a good deal slower than DRAM cells, but they can work well for server systems. They are not SRAM - that's a different thing.
Yes, these options are already available - and most software uses them (some legacy stuff does not work with them enabled). I did not mean "I agree with you that we should have these features" - I meant "I agree with you that these features are a good idea".
Such compilers are useless for embedded systems, in which RAM and xxROM memories are used. You really need to ne able control, what kind of sections goes to which kind of memory.
Or use user selectable section names with similar attributes.
Some processors might have (or just support) separate instruction and data spaces, so a section must be loaded into correct address space.
In old days, self-modifying code was a necessity in order to access an array, by modifying the address part of the instruction word. When most hardware started to support an index register, the need for self modifying code quickly disappeared. This happened already in the
1960's.
Punched cards users were encouraged to draw a diagonal india ink line across their card decks, in case the operator dropped the card deck:-).
Of course the FORTRAN by reference subroutine parameter passing could cause problems as above.I don't know if such trick would cause such problems in in-line code, but definitely in subroutine calling.
What is a string ? FORTRAN IV and earlier only had arrays (some even array of chars) :-).
This is always the problem.
Or write passwords on Post-It labels etc.
You really need to find a realistic compromise.
In countries, in which a person disobeying some rules can be immediately shot, defining draconian rules is possible, but in a western democracy, this is not possible.
I have done system managed on various VAX/VMS system since the 1980's and I agree it is much cleaner than current systems. For instance new application installation was done by the system manager to all users at once.
Intel has had some segment level protection since the 286/386 days, but MS did not use it. The "NX" bit is only available in the PAE (Physical Address Extension) page table entry.
The problem is that the execution control (NX) was not present in 386 page table entries, just in PAE page table entries.
There's no reason that an embedded system couldn't use a secure compiler and OS.
Our embedded systems load programs from nv memory, usually flash, but run out of RAM: SRAM for simple systems, DRAM for bigger ones. We never map slow nv memory into CPU data or code spaces; that would be too slow.
It takes real talent to make an embedded system subject to malware, but people do manage it.
In the early DOS days, there was a joke that a JPEG image could contain a virus. When they wrote Windows, Microsoft made that possible.
--
John Larkin Highland Technology, Inc trk
jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com
In reality, the embedded security is simply enforced by controlling the physical access to the device.
Burn EPROMS, it keeps most hackers away.
I once suggested using bloodhounds for enforcing the physicals protection. The problem was how to train the bloodhounds not to eat our service technicians but only local hackers.
If there are not enough local hackers, some other meet is needed to keep these dogs happy, which becomes expensive. For some strange reason, I was called a racist and my data protection suggestion was not accepted ;-) :-)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.