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
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.
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:I'm not sure about today, but that late there were still people
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:<snippo>
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 heI tested the OpenWatcom Usenet server, and Agent reported no response.
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.) --- Synchronet 3.21a-Linux NewsLink 1.2
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.
On Tue, 4 Nov 2025 12:15:27 -0500, geodandw wrote:
The 68000 was a very nice processor for its time. It's too bad IBM
didn't use it in the PC.
Might have been a cost issue (more pins, more cost).
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 05/11/2025 16:15, Scott Lurndal wrote:
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.
Fair enough, now I see what you are getting at. Yes, once you are
outside the Cortex-M core and key ARM-supplied components (like the interrupt controller), you as a SoC designer are free to do what you
like. And if you have a 32-bit processor that needs access to a 64-bit address space, you are going to have to do some kind of windowing or segmenting.
In the SoC's I have used where 64-bit Cortex-A processors are combined
with a Cortex-M core for security purposes, booting, or for better real- time control of peripherals, the Cortex-M device does not have direct
access to the 64-bit memory space. It has access to the peripherals,
some dedicated memory, and a message-passing interface with the Cortex-A cores.
But in your work, you probably see more variety and more possibilities
for these things - I only get to use the chips someone else has made!
On 06/11/2025 07:51, David Brown wrote:
On 05/11/2025 16:15, Scott Lurndal wrote:
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.
Fair enough, now I see what you are getting at. Yes, once you are
outside the Cortex-M core and key ARM-supplied components (like the
interrupt controller), you as a SoC designer are free to do what you
like. And if you have a 32-bit processor that needs access to a
64-bit address space, you are going to have to do some kind of
windowing or segmenting.
In the SoC's I have used where 64-bit Cortex-A processors are combined
with a Cortex-M core for security purposes, booting, or for better
real- time control of peripherals, the Cortex-M device does not have
direct access to the 64-bit memory space. It has access to the
peripherals, some dedicated memory, and a message-passing interface
with the Cortex-A cores.
But in your work, you probably see more variety and more possibilities
for these things - I only get to use the chips someone else has made!
I think you were right, if this 'M7' chip doesn't directly have
registers, instructions or infrastructure to access the more complex
memory system.
Unless you are modifying M7 itself, then that 'glue' logic could be
applied to anything (eg. I've built a Z80 system with 256KB RAM), and it
is that composite system that a language + compiler can target.
Then it would appear to the use of the language that the target machine
had those extended features. But if they were to look at the generated
code, they might see it was accessing external registers or whatever.
So it's cheating.
On 06/11/2025 12:21, bart wrote:
On 06/11/2025 07:51, David Brown wrote:
On 05/11/2025 16:15, Scott Lurndal wrote:
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.
Fair enough, now I see what you are getting at. Yes, once you are
outside the Cortex-M core and key ARM-supplied components (like
the interrupt controller), you as a SoC designer are free to do
what you like. And if you have a 32-bit processor that needs
access to a 64-bit address space, you are going to have to do some
kind of windowing or segmenting.
In the SoC's I have used where 64-bit Cortex-A processors are
combined with a Cortex-M core for security purposes, booting, or
for better real- time control of peripherals, the Cortex-M device
does not have direct access to the 64-bit memory space. It has
access to the peripherals, some dedicated memory, and a
message-passing interface with the Cortex-A cores.
But in your work, you probably see more variety and more
possibilities for these things - I only get to use the chips
someone else has made!
I think you were right, if this 'M7' chip doesn't directly have
registers, instructions or infrastructure to access the more
complex memory system.
Unless you are modifying M7 itself, then that 'glue' logic could be applied to anything (eg. I've built a Z80 system with 256KB RAM),
and it is that composite system that a language + compiler can
target.
Then it would appear to the use of the language that the target
machine had those extended features. But if they were to look at
the generated code, they might see it was accessing external
registers or whatever.
So it's cheating.
You were fine up until the last sentence here. What do you mean by "cheating" ? Whose rules is it breaking? The system Scott was
describing (assuming I understood him correctly) let the 32-bit core
access blocks of the 64-bit address space. You can choose which part
of the address space is accessible at any given time (presumably by accessing segment or window registers like any other memory-mapped peripheral registers). But you can't call it "cheating" unless you
have defined some set of rules for what is "allowed" and what is not
allowed, and everyone else has agreed to play by those rules.
On Thu, 6 Nov 2025 13:56:17 +0100
David Brown <david.brown@hesbynett.no> wrote:
On 06/11/2025 12:21, bart wrote:
On 06/11/2025 07:51, David Brown wrote:
On 05/11/2025 16:15, Scott Lurndal wrote:
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.
Fair enough, now I see what you are getting at. Yes, once you are
outside the Cortex-M core and key ARM-supplied components (like
the interrupt controller), you as a SoC designer are free to do
what you like. And if you have a 32-bit processor that needs
access to a 64-bit address space, you are going to have to do some
kind of windowing or segmenting.
In the SoC's I have used where 64-bit Cortex-A processors are
combined with a Cortex-M core for security purposes, booting, or
for better real- time control of peripherals, the Cortex-M device
does not have direct access to the 64-bit memory space. It has
access to the peripherals, some dedicated memory, and a
message-passing interface with the Cortex-A cores.
But in your work, you probably see more variety and more
possibilities for these things - I only get to use the chips
someone else has made!
I think you were right, if this 'M7' chip doesn't directly have
registers, instructions or infrastructure to access the more
complex memory system.
Unless you are modifying M7 itself, then that 'glue' logic could be
applied to anything (eg. I've built a Z80 system with 256KB RAM),
and it is that composite system that a language + compiler can
target.
Then it would appear to the use of the language that the target
machine had those extended features. But if they were to look at
the generated code, they might see it was accessing external
registers or whatever.
So it's cheating.
You were fine up until the last sentence here. What do you mean by
"cheating" ? Whose rules is it breaking? The system Scott was
describing (assuming I understood him correctly) let the 32-bit core
access blocks of the 64-bit address space. You can choose which part
of the address space is accessible at any given time (presumably by
accessing segment or window registers like any other memory-mapped
peripheral registers). But you can't call it "cheating" unless you
have defined some set of rules for what is "allowed" and what is not
allowed, and everyone else has agreed to play by those rules.
Doing this sort of tricks with Cortex-M7 is asking for trouble.
Its
data cache is unaware of tricks you play with windows, so programmer
have to flush/invalidate cache lines manually.
Sooner or later
programmer will make mistake. A mistake of the sort that is very hard to debug.
I'd say, if you (SOC designer) absolutely have to play these games, just
use Cortex-M4.
On Thu, 6 Nov 2025 13:56:17 +0100
David Brown <david.brown@hesbynett.no> wrote:
On 06/11/2025 12:21, bart wrote:
On 06/11/2025 07:51, David Brown wrote: =20=20
On 05/11/2025 16:15, Scott Lurndal wrote: =20=20
David Brown <david.brown@hesbynett.no> writes: =20
On 04/11/2025 23:04, Scott Lurndal wrote: =20
David Brown <david.brown@hesbynett.no> writes: =20
On 04/11/2025 18:32, Scott Lurndal wrote: =20=20
.=A0 (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. =20
I have used Cortex-M devices with programmable windows
in the physical address space. =20
OK.=A0 I have not, but I haven't used the newer Cortex-M cores as
yet, so it could well be a new feature. =20
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.=A0=A0 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.
=20
Fair enough, now I see what you are getting at.=A0 Yes, once you are=20 >> >> outside the Cortex-M core and key ARM-supplied components (like
the interrupt controller), you as a SoC designer are free to do
what you like.=A0 And if you have a 32-bit processor that needs
access to a 64-bit address space, you are going to have to do some
kind of windowing or segmenting.
In the SoC's I have used where 64-bit Cortex-A processors are
combined with a Cortex-M core for security purposes, booting, or
for better real- time control of peripherals, the Cortex-M device
does not have direct access to the 64-bit memory space.=A0 It has
access to the peripherals, some dedicated memory, and a
message-passing interface with the Cortex-A cores.
But in your work, you probably see more variety and more
possibilities for these things - I only get to use the chips
someone else has made!=20
I think you were right, if this 'M7' chip doesn't directly have=20
registers, instructions or infrastructure to access the more
complex memory system.
=20
Unless you are modifying M7 itself, then that 'glue' logic could be=20
applied to anything (eg. I've built a Z80 system with 256KB RAM),
and it is that composite system that a language + compiler can
target.
=20
Then it would appear to the use of the language that the target
machine had those extended features. But if they were to look at
the generated code, they might see it was accessing external
registers or whatever.
=20
So it's cheating. =20
You were fine up until the last sentence here. What do you mean by=20
"cheating" ? Whose rules is it breaking? The system Scott was=20
describing (assuming I understood him correctly) let the 32-bit core=20
access blocks of the 64-bit address space. You can choose which part
of the address space is accessible at any given time (presumably by=20
accessing segment or window registers like any other memory-mapped=20
peripheral registers). But you can't call it "cheating" unless you
have defined some set of rules for what is "allowed" and what is not
allowed, and everyone else has agreed to play by those rules.
=20
=20
Doing this sort of tricks with Cortex-M7 is asking for trouble. Its
data cache is unaware of tricks you play with windows, so programmer
have to flush/invalidate cache lines manually.
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>,This is all very interesting as a summary of where-we-are. Thanks.
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.
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.
On Thu, 6 Nov 2025 13:56:17 +0100
David Brown <david.brown@hesbynett.no> wrote:
On 06/11/2025 12:21, bart wrote:
On 06/11/2025 07:51, David Brown wrote:
On 05/11/2025 16:15, Scott Lurndal wrote:
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.
Fair enough, now I see what you are getting at. Yes, once you are
outside the Cortex-M core and key ARM-supplied components (like
the interrupt controller), you as a SoC designer are free to do
what you like. And if you have a 32-bit processor that needs
access to a 64-bit address space, you are going to have to do some
kind of windowing or segmenting.
In the SoC's I have used where 64-bit Cortex-A processors are
combined with a Cortex-M core for security purposes, booting, or
for better real- time control of peripherals, the Cortex-M device
does not have direct access to the 64-bit memory space. It has
access to the peripherals, some dedicated memory, and a
message-passing interface with the Cortex-A cores.
But in your work, you probably see more variety and more
possibilities for these things - I only get to use the chips
someone else has made!
I think you were right, if this 'M7' chip doesn't directly have
registers, instructions or infrastructure to access the more
complex memory system.
Unless you are modifying M7 itself, then that 'glue' logic could be
applied to anything (eg. I've built a Z80 system with 256KB RAM),
and it is that composite system that a language + compiler can
target.
Then it would appear to the use of the language that the target
machine had those extended features. But if they were to look at
the generated code, they might see it was accessing external
registers or whatever.
So it's cheating.
You were fine up until the last sentence here. What do you mean by
"cheating" ? Whose rules is it breaking? The system Scott was
describing (assuming I understood him correctly) let the 32-bit core
access blocks of the 64-bit address space. You can choose which part
of the address space is accessible at any given time (presumably by
accessing segment or window registers like any other memory-mapped
peripheral registers). But you can't call it "cheating" unless you
have defined some set of rules for what is "allowed" and what is not
allowed, and everyone else has agreed to play by those rules.
Doing this sort of tricks with Cortex-M7 is asking for trouble. Its
data cache is unaware of tricks you play with windows, so programmer
have to flush/invalidate cache lines manually. Sooner or later
programmer will make mistake.
A mistake of the sort that is very hard to debug.
I'd say, if you (SOC designer) absolutely have to play these games, just
use Cortex-M4.
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"?
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,076 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 81:36:11 |
| Calls: | 13,805 |
| Files: | 186,990 |
| D/L today: |
7,339 files (2,462M bytes) |
| Messages: | 2,443,323 |