Prev: "what a crock the X86 architecture is"
Next: x86 instruction set usage-difference between windows 95 and windows xp ?
From: Jonathan de Boyne Pollard on 24 Mar 2010 22:29
>
>
>> I'm sure there have been a number of processors with segmented
>> architectures, and that a number of them will have had C compilers,
>> so there are almost certainly more.
>>
> The IBM 360 mainframe line (designed in the early 1960-s) is probably
> the earliest segmented architecture, but it never had the limitations
> of the Intel architecture. Register size was 32 b, regardless of the
> width of the memory bus (which was available in all power-of-two sizes
> from 8-b to 128-b width, depending on your budget), and registers
> could address all memory. All pointers were flat model pointers.
>
We were discussing the 68xx and 680x0 processors earlier in this thread,
and the reasons to like them. Having general-purpose registers that
were as big as full memory addresses (at the instruction set level) is
definitely one such reason. It raises an interesting question, though.
How many CPUs in the modern personal computer market, or indeed in the
modern computer market overall, is that still true of? Not having
general-purpose registers as wide as memory addresses has long been the
case for the majority (given the popularity of the x86 architecture).
But has it now become universally the case?

From: Jonathan de Boyne Pollard on 24 Mar 2010 22:44
>
>
> One of the major problems with the Intel-related terms "16-bit",
> "32-bit", and "64-bit" is that unlike other vendors' architectures,
> Intel makes the widths of the storage data bus, of the storage address
> bus, and of the arithmetic unit integer register identical (with a
> few, early exceptions, e.g., 8088). Other manufacturers make use of
> the logical independence of those sizes for such things as reduced
> component manufacturing cost, machines scalable to your budget without
> software change, etc. It is a travesty that some OS vendors' newer OS
> versions do not support older programs that were written for some of
> their own prior OS versions, and which the hardware fully supports.
>
Which processor architecture are you implying those operating systems
run on? Intel? Or the "other manufacturers'"?

From: io_x on 28 Mar 2010 06:47

"Jonathan de Boyne Pollard" <J.deBoynePollard-newsgroups(a)NTLWorld.COM> ha
scritto nel messaggio
news:IU.D20100327.T052544.P2443.Q0(a)J.de.Boyne.Pollard.localhost...
> >
>>>
>>> The thing is, you can laugh yourself silly now. Henry Spencer gave "All the
>>> world's a 386." as a heresy equivalent to "All the world's a VAX.". The
>>> people who argue that the whole planet is flat, because their platform of
>>> choice gives them a tiny/flat memory model, are forgetting that the very
>>> processor architecture that they are using is one of the
>>> reasons that the C and C++ languages are careful not to provide such
>>> sweeping conversion (and other) semantics for pointers in the first place.
>>>
>> Maybe one of the reasons, but machines like the PDP-10 are another. [...
>> discussion of pointers to 9-bit char on PDP-10 ...]
>>
> Which is why I didn't say "the reason". (-: It's worth thinking about
> whether there now exist many mainstream processor architectures that provide
> flat addressing where instruction set addresses are the same width as, or
> narrower than, the general-purpose data registers, and whether processor
> architectures that are even close to the I=L=P model are not overwhelmingly in
> the minority. It's true for IA64 that IS addresses are the same width as data
> registers (GR0 and IP being both 64 bits wide). It's also true for the 68xx
> and the 680x0 architectures, that M. Flass was lamenting, earlier, to be
> rarities these days, and no longer really part of the personal computer
> market. It's certainly not the case for the x86 architecture (48-bit CS:EIP
> being wider than 32-bit EAX).

is it possible to use 48-bit CS:EAX for point one big array
of len=3FFF_FFFF_FFFF in one program?

something like

..0:
mov bl, CS:eax
inc eax
jnc .1
inc CS
..1: push ebx
call f
etc etc


>It's not the case for AS/400s, where SLS pointers are 128 bits and Teraspace
>pointers are 64 bits, and hence the choices are 4-4-16 (ILP) and 4-4-8.
>



From: io_x on 28 Mar 2010 11:36

"io_x" <a(a)b.c.invalid> ha scritto nel messaggio
news:4baf3197$0$1143$4fafbaef(a)reader1.news.tin.it...
> is it possible to use 48-bit CS:EAX for point one big array
> of len=3FFF_FFFF_FFFF in one program?
>
> something like
>
> .0:
> mov bl, CS:eax
mov bl, [CS:eax]
> inc eax
> jnc .1
> inc CS
> .1: push eax
push ebx
> call f
pop eax
jnc .0


From: Kalle Olavi Niemitalo on 28 Mar 2010 15:25
(comp.lang.c dropped; comp.lang.asm.x86 not added because
I don't read that)

"io_x" <a(a)b.c.invalid> writes:

> is it possible to use 48-bit CS:EAX for point one big array
> of len=3FFF_FFFF_FFFF in one program?

The array would have to be smaller because selectors 0 to 3
are reserved for null pointers and you'd also need several
segments for the application and the kernel: code segment,
stack segment, task state segment, probably others I forget.
3FF0_0000_0000 might be doable but it would need tricks in the
kernel and probably perform worse than asynchronous read/write
system calls.

Because the 80386 converts segment:offset pairs to 32-bit linear
addresses before it uses the page tables to convert the linear
addresses to physical addresses, it is difficult to actually use
all the bytes of maximum-size segments. I think the kernel could
work around this by first making the segment allow offsets
0000_0000 ... 7FFF_FFFF and map them to linear addresses
8000_0000 ... FFFF_FFFF; when the application exceeds this range,
the kernel would swap the data out, redefine the segment to map
offsets 8000_0000 ... FFFF_FFFF (using the expand-down bit in the
segment descriptor) to linear addresses 8000_0000 ... FFFF_FFFF,
and swap the other data in. This would leave the lower half of
the linear address space available for code, stacks, page tables,
and other purposes.

The operating system might also prefer having all the program's
own segments in the local descriptor table, rather than half
local and half global. If so, that'll cost you another bit in
the segment selector values. However, if the kernel is willing
to do the expand-down hack, then I suppose it can accommodate
the application in this way too.

> inc CS

The code segment register CS cannot be used for this.
The stack segment register SS is also inadvisable.
DS, ES, FS, or GS would work.

Also, you'd have to increment the register by 4 because the
lowest two bits indicate the privilege level, or by 8 if using
only segments defined in the local descriptor table.
And of course there are no arithmetic instructions for segment
registers, so you'd have to increment a general-purpose register
and copy the value from there.
 |  Next  |  Last
Pages: 1 2
Prev: "what a crock the X86 architecture is"
Next: x86 instruction set usage-difference between windows 95 and windows xp ?