Hello from Gregg C Levine Right John. The I8080 in its original form ran at 800Khz, then when it finally ran out, so to speak, they were up to about 4Mhz, but only in small lots. The rest of what you are writing about, you are quite correct. ------------------- Gregg C Levine [EMAIL PROTECTED] ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda )
> -----Original Message----- > From: Linux on 390 Port [mailto:LINUX-390@;VM.MARIST.EDU] On Behalf Of > John Summerfield > Sent: Monday, November 04, 2002 9:03 PM > To: [EMAIL PROTECTED] > Subject: Re: [LINUX-390] Probably the first published shell code example for > Linux/390 > > On Mon, 4 Nov 2002 23:32, Scott Courtney wrote: > > > because often the applications were simple enough not to need them. And > > because dynamic memory structures needed to be managed by the application > > or at least the compiler runtime, and that took CPU cycles. With a clock > > speed of around 2 megahertz, and cycle times measured in microseconds, > > this mattered a lot. > > I know I'm being picky, but the 8080 wasn't that fast. Around 800 Khz I think. > > > > > Incidentally, I noted in one other post a comment that there should be > > hardware protection to keep from executing instructions off the stack. > > Great idea. Starting with the 8086, Intel *had* this hardware protection, > > because the stack had its own memory segment that could be physically > > isolated from other segments. You had to explicitly set the code segment > > register to point into the stack segment if you wanted to execute stack > > data as code. The 8086 didn't have any security features to keep malicious > > code from doing this, but at least it didn't happen by accident. Starting > > with the 80286, there were actually security privilege levels that kept > > application programs from tinkering with segment registers -- as long as > > you were running in an operating system that supported this. DOS, of > > course, didn't. > > > > Then came our modern age, the age of flat memory models. Segment registers > > are anachronistic. Toss them out. One simple, flat memory model is the only > > way to go. > > The segment registers still exist. Their use was expanded and they got > renamed. > > On the 8086 family, segments were 64K. One the 80286 you can limit the size of > segments through the use of segment descriptors, and the registers accessing > them are segment selectors. > > With the advent of the 80386 with 32-bit offsets, software authors said > "That's heaps, well use single 4 Gbyte address spaces, one for code, data and > stack combined." A reason was performance. > > I'd have thought most of the performance benefits would be achieved with a > 32-bit address space for each, and you'd have much less trouble with array > overruns and such. > > > > > Hello simple memory management and portability. Bye-bye hardware stack > > protection. > > > > To be fair, I should mention that I generally *agree* with the flat memory > > model. It really goes a long way toward improving portability, since there > > are tons of hardware architectures that have no analogue to the Intel > > segment registers. But in dumping the segment registers, we didn't get our > > lunch totally for free. <GRIN> > > > Some of those architectures came later, and if software authors had _used_ the > Intel protection abilities, those architectures may well have been different. > > > > > -- > Cheers > John Summerfield > > > Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ > Join the "Linux Support by Small Businesses" list at > http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
