On 24 Mar, 23:40, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
wrote:
Dann Corbit <dcor...@connx.com> writes:
In article <1e27d5ee-a1b1-45d9-9188-
63ab37398...@d37g2000yqn.googlegroups.com>,
nick_keighley_nos...@hotmail.com says...
On 23 Mar, 20:56, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
In alt.sys.pdp10 Richard Bos <ralt...@xs4all.nl> wrote:
(snip)
That crossposting was, for once, not asinine. It served as a nice
example why, even now, Leenux weenies are not correct when they insist >>>>>> that C has a flat memory model and all pointers are just numbers.
Well, you could also read the C standard to learn that.
but if you say that you get accused of language lawyering.
"Since IBM stopped making 360s no C program ever needs to run on such
a platform"
We have customers who are running their business on harware from the mid >>> 1980s. ˙It may sound ludicrous, but it if solves all of their business
needs, and runs solid 24x365, why should they upgrade?
Because they could run an equivalently computationally powerful
solution with various levels of redundancy and fail-over protection,
with a power budget sensibly measured in mere Watts?
does it have a Coral compiler?
In alt.sys.pdp10 Richard Bos <raltbos@xs4all.nl> wrote:
(snip)
That crossposting was, for once, not asinine. It served as a nice
example why, even now, Leenux weenies are not correct when they insist
that C has a flat memory model and all pointers are just numbers.
Well, you could also read the C standard to learn that.
There are additional complications for C on the PDP-10.
-- glen
The fact that I've heard exactly the same argument made about Visual
As has been said here many times, different languages have different
problem domains.˙ Most of the trouble people have is caused by using
the wrong language for what they're trying to do.˙ It used to be
Fortran or COBOL, now, apparently, it's stuff like Java.
The attraction of Java is obvious; you can hire cheap inexperienced
unskilled individuals to crank out Java code.
Typically, a fair amount of a programming class washes out when you
get to teaching pointers and structures.˙ Some wash out even earlier
on recursion.˙ These individuals were lost to employers, who had to
spend a great deal more on skilled individuals who could understand
such things.
Java fixed that.˙ Thanks to Java, any snot-nosed kid can write
Important Applications.
They just won't be very robust applications.
BASIC, ten years ago, casts heavy doubt on the fact that it's Java that
is to blame for all of the world's ills.
Branimir Maksimovic wrote:
On Tue, 23 Mar 2010 06:51:18 -0400
Peter Flass <Peter_Flass@Yahoo.com> wrote:
Jonathan de Boyne Pollard wrote:
Returning to what we were talking about before the silly diversion,Flat memory model.
I should point out that 32-bit applications programming where the
target is extended DOS or 32-bit Win16 (with OpenWatcom's extender)
will also occasionally employ 16:32 far pointers of course.˙ But as
I said before, regular 32-bit OS/2 or Win32 applications
programming generally does not, since those both use the Tiny
memory model,
Problem with standard C and C++ is that they assume flat memory
model.
I'm not a C expert, perhaps you're a denizen of comp.lang.c, but as far
as I know there's nothing in the C standard that assumes anything about pointers, except that they have to be the same size as int, so for 16:32 pointers I guess you'd need 64-bit ints.
As far as implementations are concerned, both Watcom and IBM VA C++
support segmented memory models.˙ These are the ones I'm aware of, there
are probably more.
On 3/31/10 13:30, Jonathan de Boyne Pollard wrote:
The fact that I've heard exactly the same argument made about Visual
As has been said here many times, different languages have different
problem domains.˙ Most of the trouble people have is caused by using
the wrong language for what they're trying to do.˙ It used to be
Fortran or COBOL, now, apparently, it's stuff like Java.
The attraction of Java is obvious; you can hire cheap inexperienced
unskilled individuals to crank out Java code.
Typically, a fair amount of a programming class washes out when you
get to teaching pointers and structures.˙ Some wash out even earlier
on recursion.˙ These individuals were lost to employers, who had to
spend a great deal more on skilled individuals who could understand
such things.
Java fixed that.˙ Thanks to Java, any snot-nosed kid can write
Important Applications.
They just won't be very robust applications.
BASIC, ten years ago, casts heavy doubt on the fact that it's Java that
is to blame for all of the world's ills.
Some people claim that for Excel.
otherwise it tries to enforce the dictum that all dates shall be in
dd/mm/yy format,
What happened here?? I just noticed that a lot of these posts are from
2010. Did some news server just barf?
On 3/23/10 14:42, Peter Flass wrote:
Branimir Maksimovic wrote:
On Tue, 23 Mar 2010 06:51:18 -0400
Peter Flass <Peter_Flass@Yahoo.com> wrote:
Jonathan de Boyne Pollard wrote:
Returning to what we were talking about before the silly diversion,Flat memory model.
I should point out that 32-bit applications programming where the
target is extended DOS or 32-bit Win16 (with OpenWatcom's extender)
will also occasionally employ 16:32 far pointers of course.˙ But as
I said before, regular 32-bit OS/2 or Win32 applications
programming generally does not, since those both use the Tiny
memory model,
Problem with standard C and C++ is that they assume flat memory
model.
I'm not a C expert, perhaps you're a denizen of comp.lang.c, but as
far as I know there's nothing in the C standard that assumes anything
about pointers, except that they have to be the same size as int, so
for 16:32 pointers I guess you'd need 64-bit ints.
As far as implementations are concerned, both Watcom and IBM VA C++
support segmented memory models.˙ These are the ones I'm aware of,
there are probably more.
On 11/2/2025 2:20 PM, Peter Flass wrote:
What happened here?? I just noticed that a lot of these posts are from
2010. Did some news server just barf?
On 3/23/10 14:42, Peter Flass wrote:
Branimir Maksimovic wrote:
On Tue, 23 Mar 2010 06:51:18 -0400
Peter Flass <Peter_Flass@Yahoo.com> wrote:
Jonathan de Boyne Pollard wrote:
Returning to what we were talking about before the silly diversion, >>>>>> I should point out that 32-bit applications programming where theFlat memory model.
target is extended DOS or 32-bit Win16 (with OpenWatcom's extender) >>>>>> will also occasionally employ 16:32 far pointers of course.˙ But as >>>>>> I said before, regular 32-bit OS/2 or Win32 applications
programming generally does not, since those both use the Tiny
memory model,
Problem with standard C and C++ is that they assume flat memory
model.
I'm not a C expert, perhaps you're a denizen of comp.lang.c, but as
far as I know there's nothing in the C standard that assumes anything
about pointers, except that they have to be the same size as int, so
for 16:32 pointers I guess you'd need 64-bit ints.
As far as implementations are concerned, both Watcom and IBM VA C++
support segmented memory models.˙ These are the ones I'm aware of,
there are probably more.
I asked Ray Banana of E-S about the openwatcom.* groups and he
resurrected them with all of their very old postings.
Lynn
On 11/3/25 13:24, Lynn McGuire wrote:
On 2025-11-03, Peter Flass <Peter@Iron-Spring.com> wrote:
On 11/3/25 13:24, Lynn McGuire wrote:
When I saw this subject line, I thought it was some necroposting to
threads from 1990.
Someone still cared about segmented x86 shit in 2010 (even if 32 bit)?
On 2025-11-03, Peter Flass <Peter@Iron-Spring.com> wrote:
On 11/3/25 13:24, Lynn McGuire wrote:
When I saw this subject line, I thought it was some necroposting to
threads from 1990.
Someone still cared about segmented x86 shit in 2010 (even if 32 bit)?
Amazing ...
On 11/2/2025 2:20 PM, Peter Flass wrote:
What happened here?? I just noticed that a lot of these posts are from
2010. Did some news server just barf?
I asked Ray Banana of E-S about the openwatcom.* groups and he
resurrected them with all of their very old postings.
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-11-03, Peter Flass <Peter@Iron-Spring.com> wrote:
On 11/3/25 13:24, Lynn McGuire wrote:
When I saw this subject line, I thought it was some necroposting to
threads from 1990.
Someone still cared about segmented x86 shit in 2010 (even if 32 bit)?
There are still people on the internet who swear that the 286 is
better than sliced bread and refuse to recognize that modern
architectures are superior.
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-11-03, Peter Flass <Peter@Iron-Spring.com> wrote:
On 11/3/25 13:24, Lynn McGuire wrote:
When I saw this subject line, I thought it was some necroposting to
threads from 1990.
Someone still cared about segmented x86 shit in 2010 (even if 32 bit)?
There are still people on the internet who swear that the 286 is
better than sliced bread and refuse to recognize that modern
architectures are superior.
On 11/4/25 08:20, Scott Lurndal wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-11-03, Peter Flass <Peter@Iron-Spring.com> wrote:
On 11/3/25 13:24, Lynn McGuire wrote:
When I saw this subject line, I thought it was some necroposting to
threads from 1990.
Someone still cared about segmented x86 shit in 2010 (even if 32 bit)?
There are still people on the internet who swear that the 286 is
better than sliced bread and refuse to recognize that modern
architectures are superior.
I was thinking, are there any segmented architectures today?
Most
disguise segmentation as a flat address space (e.g. IBM System/370 et.seq.)
On 04/11/2025 15:20, Scott Lurndal wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-11-03, Peter Flass <Peter@Iron-Spring.com> wrote:
On 11/3/25 13:24, Lynn McGuire wrote:
When I saw this subject line, I thought it was some necroposting to
threads from 1990.
Someone still cared about segmented x86 shit in 2010 (even if 32 bit)?
There are still people on the internet who swear that the 286 is
better than sliced bread and refuse to recognize that modern
architectures are superior.
I can still hear them down the hall.
ST!
.......................................................Amiga!
ST!
.......................................................Amiga!
The 68000 was a very nice processor for its time. It's too bad IBM
didn't use it in the PC.
Peter Flass <Peter@Iron-Spring.com> writes:
On 11/4/25 08:20, Scott Lurndal wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-11-03, Peter Flass <Peter@Iron-Spring.com> wrote:
On 11/3/25 13:24, Lynn McGuire wrote:
When I saw this subject line, I thought it was some necroposting to
threads from 1990.
Someone still cared about segmented x86 shit in 2010 (even if 32 bit)?
There are still people on the internet who swear that the 286 is
better than sliced bread and refuse to recognize that modern
architectures are superior.
I was thinking, are there any segmented architectures today?
Only in emulation (see Unisys Clearpath, for example).
scott@slp53.sl.home (Scott Lurndal) writes:
Peter Flass <Peter@Iron-Spring.com> writes:
On 11/4/25 08:20, Scott Lurndal wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-11-03, Peter Flass <Peter@Iron-Spring.com> wrote:There are still people on the internet who swear that the 286 is
On 11/3/25 13:24, Lynn McGuire wrote:
When I saw this subject line, I thought it was some necroposting to
threads from 1990.
Someone still cared about segmented x86 shit in 2010 (even if 32 bit)? >>>>
better than sliced bread and refuse to recognize that modern
architectures are superior.
I was thinking, are there any segmented architectures today?
Only in emulation (see Unisys Clearpath, for example).
Although it's worth pointing out that harvard architectures
still exist (e.g. CEVA DSPs) and the low-power ARM
scott@slp53.sl.home (Scott Lurndal) writes:
Peter Flass <Peter@Iron-Spring.com> writes:
On 11/4/25 08:20, Scott Lurndal wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-11-03, Peter Flass <Peter@Iron-Spring.com> wrote:There are still people on the internet who swear that the 286 is
On 11/3/25 13:24, Lynn McGuire wrote:
When I saw this subject line, I thought it was some necroposting to
threads from 1990.
Someone still cared about segmented x86 shit in 2010 (even if 32 bit)? >>>>
better than sliced bread and refuse to recognize that modern
architectures are superior.
I was thinking, are there any segmented architectures today?
Only in emulation (see Unisys Clearpath, for example).
Although it's worth pointing out that harvard architectures
still exist (e.g. CEVA DSPs)
and the low-power ARM
M-series core 32-bit physical address space is
divided into 28-bit regions some of which may
provide programmable windows into alternate address spaces
in a fashion very similar to segmentation.
On 04/11/2025 18:32, Scott Lurndal wrote:
. (And I have never
seen a Cortex-M device with programmable windows or addresses - indeed,
I believe the Cortex-M core documentation specifies some memory ranges >explicitly.
I was thinking, are there any segmented architectures today?
The 68000 was a very nice processor for its time. It's too bad IBM
didn't use it in the PC.
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-11-03, Peter Flass <Peter@Iron-Spring.com> wrote:
On 11/3/25 13:24, Lynn McGuire wrote:
When I saw this subject line, I thought it was some necroposting to
threads from 1990.
Someone still cared about segmented x86 shit in 2010 (even if 32 bit)?
There are still people on the internet who swear that the 286 is
better than sliced bread and refuse to recognize that modern
architectures are superior.
David Brown <david.brown@hesbynett.no> writes:
On 04/11/2025 18:32, Scott Lurndal wrote:
. (And I have never
seen a Cortex-M device with programmable windows or addresses - indeed,
I believe the Cortex-M core documentation specifies some memory ranges
explicitly.
I have used Cortex-M devices with programmable windows
in the physical address space.
On 04/11/2025 23:04, Scott Lurndal wrote:
David Brown <david.brown@hesbynett.no> writes:
On 04/11/2025 18:32, Scott Lurndal wrote:
. (And I have never
seen a Cortex-M device with programmable windows or addresses - indeed,
I believe the Cortex-M core documentation specifies some memory ranges
explicitly.
I have used Cortex-M devices with programmable windows
in the physical address space.
OK. I have not, but I haven't used the newer Cortex-M cores as yet, so
it could well be a new feature.
David Brown <david.brown@hesbynett.no> writes:
On 04/11/2025 23:04, Scott Lurndal wrote:
David Brown <david.brown@hesbynett.no> writes:
On 04/11/2025 18:32, Scott Lurndal wrote:
. (And I have never
seen a Cortex-M device with programmable windows or addresses - indeed, >>>> I believe the Cortex-M core documentation specifies some memory ranges >>>> explicitly.
I have used Cortex-M devices with programmable windows
in the physical address space.
OK. I have not, but I haven't used the newer Cortex-M cores as yet, so
it could well be a new feature.
It is not necessarily a feature of the M7 core itself, but rather
the glue logic around it - particularly the logic that interfaces
to the "system bus" to which the M7 core is interfaced. That logic
is under the control of the SoC designer and can easily have
external registers that are programmed to specify how to route
accesses from the M7, including to large regions of DRAM;
consider a maintenance processor on a 64-bit server that needs
access to the server DRAM space for RAS purposes.
On 11/4/25 08:20, Scott Lurndal wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-11-03, Peter Flass <Peter@Iron-Spring.com> wrote:
On 11/3/25 13:24, Lynn McGuire wrote:
When I saw this subject line, I thought it was some necroposting to
threads from 1990.
Someone still cared about segmented x86 shit in 2010 (even if 32 bit)?
There are still people on the internet who swear that the 286 is
better than sliced bread and refuse to recognize that modern
architectures are superior.
I was thinking, are there any segmented architectures today? Most
disguise segmentation as a flat address space (e.g. IBM System/370 et.seq.)
In article <10eda8d$3pd45$1@dont-email.me>,
Peter Flass <Peter@Iron-Spring.com> wrote:
On 11/4/25 08:20, Scott Lurndal wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-11-03, Peter Flass <Peter@Iron-Spring.com> wrote:
On 11/3/25 13:24, Lynn McGuire wrote:
When I saw this subject line, I thought it was some necroposting to
threads from 1990.
Someone still cared about segmented x86 shit in 2010 (even if 32 bit)?
There are still people on the internet who swear that the 286 is
better than sliced bread and refuse to recognize that modern
architectures are superior.
I was thinking, are there any segmented architectures today? Most
disguise segmentation as a flat address space (e.g. IBM System/370 et.seq.)
x86_64 is still nominally segmented; what "code segment" the
processor is running in matters, even in long mode. But most of
the segment data is ignored by hardware (e.g., base and limits)
in 64-bit mode.
In article <10eda8d$3pd45$1@dont-email.me>,bit)?
Peter Flass <Peter@Iron-Spring.com> wrote:
On 11/4/25 08:20, Scott Lurndal wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-11-03, Peter Flass <Peter@Iron-Spring.com> wrote:
On 11/3/25 13:24, Lynn McGuire wrote:
When I saw this subject line, I thought it was some necroposting to
threads from 1990.
Someone still cared about segmented x86 shit in 2010 (even if 32
et.seq.)
There are still people on the internet who swear that the 286 is
better than sliced bread and refuse to recognize that modern
architectures are superior.
I was thinking, are there any segmented architectures today? Most
disguise segmentation as a flat address space (e.g. IBM System/370
x86_64 is still nominally segmented; what "code segment" the
processor is running in matters, even in long mode. But most of
the segment data is ignored by hardware (e.g., base and limits)
in 64-bit mode.
Of course, it retains a notion of segmentation for a) 16- and
32-bit code compatibility, and b) startup, where the processor
(still!!) comes out of reset in 16-bit real mode.
Intel had a proposal to do away with 16-bit mode and anything
other than long mode for 64-bit, but it seems to have died. So
it seems like we'll be stuck with x86 segmentation --- at least
for compatibility purposes --- for a while longer still.
On 11/4/25 12:12, Richard Heathfield wrote:
On 04/11/2025 15:20, Scott Lurndal wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-11-03, Peter Flass <Peter@Iron-Spring.com> wrote:
On 11/3/25 13:24, Lynn McGuire wrote:
When I saw this subject line, I thought it was some necroposting to
threads from 1990.
Someone still cared about segmented x86 shit in 2010 (even if 32 bit)?
There are still people on the internet who swear that the 286 is
better than sliced bread and refuse to recognize that modern
architectures are superior.
I can still hear them down the hall.
ST!
.......................................................Amiga!
ST!
.......................................................Amiga!
The 68000 was a very nice processor for its time. It's too bad IBM
didn't use it in the PC.
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <10eda8d$3pd45$1@dont-email.me>,
Peter Flass <Peter@Iron-Spring.com> wrote:
On 11/4/25 08:20, Scott Lurndal wrote:x86_64 is still nominally segmented; what "code segment" the
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-11-03, Peter Flass <Peter@Iron-Spring.com> wrote:There are still people on the internet who swear that the 286 is
On 11/3/25 13:24, Lynn McGuire wrote:
When I saw this subject line, I thought it was some necroposting to
threads from 1990.
Someone still cared about segmented x86 shit in 2010 (even if 32 bit)? >>>>
better than sliced bread and refuse to recognize that modern
architectures are superior.
I was thinking, are there any segmented architectures today? Most >>>disguise segmentation as a flat address space (e.g. IBM System/370 et.seq.) >>
processor is running in matters, even in long mode. But most of
the segment data is ignored by hardware (e.g., base and limits)
in 64-bit mode.
Minor correction, an update to AMD64 was done back in
the oughts to support some segment limit registers for 64-bit XEN
(and probably for vmware as well).
See the LMSLE bit in the EFER register for more details.
On Fri, 7 Nov 2025 15:50:53 -0000 (UTC), cross@spitfire.i.gajendra.net
(Dan Cross) wrote:
In article <10eda8d$3pd45$1@dont-email.me>,
Peter Flass <Peter@Iron-Spring.com> wrote:
On 11/4/25 08:20, Scott Lurndal wrote:x86_64 is still nominally segmented; what "code segment" the
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-11-03, Peter Flass <Peter@Iron-Spring.com> wrote:There are still people on the internet who swear that the 286 is
On 11/3/25 13:24, Lynn McGuire wrote:
When I saw this subject line, I thought it was some necroposting to
threads from 1990.
Someone still cared about segmented x86 shit in 2010 (even if 32 bit)? >>>>
better than sliced bread and refuse to recognize that modern
architectures are superior.
I was thinking, are there any segmented architectures today? Most >>>disguise segmentation as a flat address space (e.g. IBM System/370 et.seq.) >>
processor is running in matters, even in long mode. But most of
the segment data is ignored by hardware (e.g., base and limits)
in 64-bit mode.
Of course, it retains a notion of segmentation for a) 16- and
32-bit code compatibility, and b) startup, where the processor
(still!!) comes out of reset in 16-bit real mode.
Intel had a proposal to do away with 16-bit mode and anything
other than long mode for 64-bit, but it seems to have died. So
it seems like we'll be stuck with x86 segmentation --- at least
for compatibility purposes --- for a while longer still.
This is all very interesting as a summary of where-we-are. Thanks.
Didn't Intel, at one time, plan to replace all xxx8x processors with
one of the new! shiny! RISC processor?
Only to be defeated when it was pointed out that a whole lot of
software would have to run on it. Software written for their xxx8x >processors, segmentation and all.
On Fri, 7 Nov 2025 15:50:53 -0000 (UTC), cross@spitfire.i.gajendra.net
(Dan Cross) wrote:
Intel had a proposal to do away with 16-bit mode and anything
other than long mode for 64-bit, but it seems to have died. So
it seems like we'll be stuck with x86 segmentation --- at least
for compatibility purposes --- for a while longer still.
This is all very interesting as a summary of where-we-are. Thanks.
Didn't Intel, at one time, plan to replace all xxx8x processors with
one of the new! shiny! RISC processor?
Didn't Intel, at one time, plan to replace all xxx8x processors with
one of the new! shiny! RISC processor?
Only to be defeated when it was pointed out that a whole lot of
software would have to run on it. Software written for their xxx8x processors, segmentation and all.
In article <10eda8d$3pd45$1@dont-email.me>,
Peter Flass <Peter@Iron-Spring.com> wrote:
On 11/4/25 08:20, Scott Lurndal wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-11-03, Peter Flass <Peter@Iron-Spring.com> wrote:
On 11/3/25 13:24, Lynn McGuire wrote:
When I saw this subject line, I thought it was some necroposting to
threads from 1990.
Someone still cared about segmented x86 shit in 2010 (even if 32 bit)?
There are still people on the internet who swear that the 286 is
better than sliced bread and refuse to recognize that modern
architectures are superior.
I was thinking, are there any segmented architectures today? Most
disguise segmentation as a flat address space (e.g. IBM System/370 et.seq.)
x86_64 is still nominally segmented; what "code segment" the
processor is running in matters, even in long mode. But most of
the segment data is ignored by hardware (e.g., base and limits)
in 64-bit mode.
Of course, it retains a notion of segmentation for a) 16- and
32-bit code compatibility, and b) startup, where the processor
(still!!) comes out of reset in 16-bit real mode.
Intel had a proposal to do away with 16-bit mode and anything
other than long mode for 64-bit, but it seems to have died. So
it seems like we'll be stuck with x86 segmentation --- at least
for compatibility purposes --- for a while longer still.
- Dan C.
In article <10edcbg$lrh1$1@dont-email.me>,
geodandw <geodandw@gmail.com> wrote:
On 11/4/25 12:12, Richard Heathfield wrote:
On 04/11/2025 15:20, Scott Lurndal wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-11-03, Peter Flass <Peter@Iron-Spring.com> wrote:There are still people on the internet who swear that the 286 is
On 11/3/25 13:24, Lynn McGuire wrote:
When I saw this subject line, I thought it was some necroposting to
threads from 1990.
Someone still cared about segmented x86 shit in 2010 (even if 32 bit)? >>>>
better than sliced bread and refuse to recognize that modern
architectures are superior.
I can still hear them down the hall.
ST!
.......................................................Amiga!
ST!
.......................................................Amiga!
The 68000 was a very nice processor for its time. It's too bad IBM
didn't use it in the PC.
They wanted to. IBM had a close relationship with Motorola, and
they even had engineering samples in Westchester. The problem
was that 68k was a skunkworks project inside of Moto, which was
pushing the 6809 as the Next Big Thing. So when IBM was talking
to Moto sales about using 68k for the PC, Moto was pushing them
(not so gently) towards the 6809 and telling them 68k was just a
research project with no future.
IBM was smart enough to know that the 6809 was going to be a
non-starter (a firmly 8-bit micro when 16-bit CPUs were becoming
mainstream), and the 8088 met their specs for the 5150, so they
went with Intel instead. By the time it was clear that the 68k
was going to be Moto's flagship CPU going forward, it was too
late for inclusion in the PC.
And here we are.
- Dan C.
I think they used the 680x0 in one of their small computers. Maybe the >"Laboratory Computer"?
the architecture. Meanwhile, a bunch of ex-DEC people went to
AMD and did the AMD64 extensions for x86, which a) performed
On Fri, 7 Nov 2025 17:22:51 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wrote:
the architecture. Meanwhile, a bunch of ex-DEC people went to
AMD and did the AMD64 extensions for x86, which a) performed
Do you have a proof that it was done by Ex-DEC people?
My impression is that Ex-DEC people, esp. Jim Keller, were very
important as micro-architects of K7 and K8, but I don't remember ever
reading that they played major role in the stage of architectural
definitions of AMD64.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 14 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 216:23:24 |
| Calls: | 184 |
| Files: | 21,502 |
| Messages: | 82,076 |