my discussions are sometimes being transferred to other forums?

I attended a presentations (by the companies concerned) on the 68000,

8086, and Z8000 in 1979.

The 68000 (and I have one wired in a board about 12" to the left of my left hand) is a proper 32-bit processor with 32-bit address registers - you can do a 32-bit add in one instruction, f'rinstance. As it happens, only 24 of the address bits are brought out to external pins, but all 32 bits are involved when an address calculation is done.

In 1979, 2^24 of memory (i.e. 16Mbytes) was Huge - oh, sorry *huge* - anyway.

You can look here:

to see what I've done with my 68k.

Reply to
Tim Streater
Loading thread data ...

Martin Brown wrote: [snip]

Only if you are talking about BillyGates ShiteWare(tm). The 64 bit OS, drivers and applications that I use have been 64 bit native for errm years.

Video conversion and filtering and crypto are both noticeably faster on the same OS run as 64bit compared with 32bit.

Reply to
Steve Firth

The CPU from that era I was most impressed by for realtime work were the TI9900 and later 99000. They were astonishingly fast at context switching since all 16 working registers including the program counter were in ram!

This could also be a serious disadvantage if the CPU register pointer ever found itself in ROM! There was always a dead man's handle/watchdog timer - which became progressively more complex as the kit found ways to die but keep on pumping the "I'm OK flag".

We didn't realise how good they were until we tried to do the same thing on a 68k later.

I did some early work on Z8000 too including the ultimately doomed Ollivetti M20. I regret not saving the Captain Zilog comics.

formatting link
> The 68000 (and I have one wired in a board about 12" to the left of my

68k was pretty good but in some ways TI9900 was better.

Humble 8bit 6502 still wins the prize for triggering affordable mass market consumer interest in home computing and games.

Reply to
Martin Brown

There have been 64-bit versions of Windows for over 10 years. There might be legacy applications and drivers that haven't caught up yet, but I'd be surprised if there's much mainstream that hasn't in cases where it matters.

Reply to
Alan Braggins

Kewl.

I always rather liked what I read about the 68k, but never worked with it.

Reply to
Huge

I wasn't suggesting that SQL was an MS idea. SNMP I know little about but had thought that it was a network thing.

If I use a WMI query to extract info about, say, threads & processes running on my own computer it's hard to see how that could be related to anything networky. I do see that there's a network capability if I want to ask the same question about activity on other machines.

Reply to
Jeremy Nicoll - news posts

I'm not familiar with the AMD part... but there was the Natsemi 32016 (or

16032, depending on which you want to call it) circa 1979, which - like the m68k - was 32 bit internals with a 16 bit external data bus. The 32032 was all 32 bit, but IIRC that didn't arrive until circa 1984.

cheers

Jules

Reply to
Jules Richardson

I don't think Mickiesoft have ever claimed to be a hardware development company. The shortage of suggestions reaffirms my original point. The only thing I can think of myself was the introduction of the directory structure into MS-Dos when they copied CP/M

Reply to
bert

I was just guarding about pedants - tis what I meant by 32 bit on the inside...

(which you could even apply to the 68008 is you want)

Reply to
John Rumm

Never tried any of the TI chips TBH. But 68K is lovely and orthogonal after x86 ;-)

Yup... the peripherals for anything wider was going to be too expensive for low end kit at that stage.

Reply to
John Rumm

The thing that always amazed me about it was the shear physical size of it - it was (and I think still is) the largest DIL packaged device I had seen!

Reply to
John Rumm

They may have been the first to stick a wheel on the top of a mouse...

Even that was only a slight step up from the groups capability in CP/M 3+

Reply to
John Rumm

I don't recall anything bigger, but the TMS9900 was physically the same size, IIRC (I still have numerous m68k-based machines, and a gold/ceramic TMS9900 rescued from an early OCR machine, but they're in storage overseas so I can't compare them right now)

As the actual heart of the IC within the packaging is very small, the length of wires needed to connect to the pins towards the ends of the device presumably becomes a major problem as device speeds increase.

cheers

Jules

Reply to
Jules Richardson

Some parts are 64bit now, but 8, 16, 32, 64 it's hardly 'innovation' to make things bigger. As for multi-core processors, that's not quite the same thing as true parallel processing, it's more like multi-tasking; parallel programming is still something of a hard problem

Reply to
djc

That's surprising. I use a 64-bit OS because I have more than 4Gb or RAM, and because sometimes I have an app that needs more than 4Gb of address space. Apart from that I've noticed no difference at all - except that 64 bit apps are a little bigger.

Andy

Reply to
Andy Champ

Hyperthreading is actually a pretty clever idea. On the principle that even with a pipeline it's pretty hard to keep the floating point adder and multiplier, the shifter, the integer adder and divider, the integer multiplier, the address translation unit etc. all busy at once they share them between two threads. That way you get a performance gain with out much extra silicon.

On the other hand, half the time the threads are fighting over the same unit, so it's not as fast as a complete extra core. But it's cheap!

Andy

Reply to
Andy Champ

Do you use ffmpeg or Handbrake? I can speed both of those up by a factor of

2 using the same hardware and 64bit versions of OS and apps 32bit.

AES 512 on 64bit is not just faster than AES 256 on 32bit. It's faster than AES 256 on 64 bit. YMMV.

Reply to
Steve Firth

A lot of this stuff is not particularly new. What is new(-ish) is that's it's cheap. Look up the CDC 6600 in WinkyPedia to get an idea.

Reply to
Tim Streater

Video and crypto apps will benefit from a greater number of wider registers, which are much faster than (even cached) memory accesses.

Reply to
Andy Burns

SNMP, like many protocols (SOAP is my favourite example, being neither simple nor object orientated) has long since gone on to bigger and better things, and providing you can define a MIB for it, you can monitor whatever you like.

Reply to
Huge

HomeOwnersHub 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.