f



64 vs. 32 bits

there is an interesting article with benchmarks regarding this subject:

 <http://www.osnews.com/story.php?news_id=5768>

BTW I think that lack of 64 bit is not a real problem for OS/2-eCS...
(or not the main problem)

--
bye
Alessandro Cantatore
email reply to: acantatore (at: tin.it)
0
tin
1/24/2004 6:12:39 AM
comp.os.os2.programmer.misc 1326 articles. 0 followers. Post Follow

119 Replies
467 Views

Similar Articles

[PageSpeed] 7

@tin.it (Alessandro Cantatore) wrote in news:CoLEAJzxPXQU092yn@tin.it:

> there is an interesting article with benchmarks regarding this 
subject:
> 
>  <http://www.osnews.com/story.php?news_id=5768>
> 
> BTW I think that lack of 64 bit is not a real problem for OS/2-eCS...
> (or not the main problem)
> 

No, because before you can gain the benefits of 64-bit computing, you 
need to drop the 16-bit code.  A pure 32-bit OS could be better than a 
hybrid 32/64-bit if it's done right, but a 16/32/64-bit OS would just be 
impossible to maintain for very long

> --
> bye
> Alessandro Cantatore
> email reply to: acantatore (at: tin.it)
> 



-- 
Don "Freiheit" Eitner
Hobby eComStation & OS/2 developer
http://freiheit.syntheticdimension.net
0
Don
1/24/2004 6:44:43 AM
"Don Eitner" <freiheit@syntheticdimension-nospam.net> wrote in message
news:Xns9479E761F71A2freiheitsyntheticdim@199.45.49.11...
> @tin.it (Alessandro Cantatore) wrote in news:CoLEAJzxPXQU092yn@tin.it:
>
> > there is an interesting article with benchmarks regarding this
> subject:
> >
> >  <http://www.osnews.com/story.php?news_id=5768>
> >
> > BTW I think that lack of 64 bit is not a real problem for OS/2-eCS...
> > (or not the main problem)
> >
>
> No, because before you can gain the benefits of 64-bit computing, you
> need to drop the 16-bit code.  A pure 32-bit OS could be better than a
> hybrid 32/64-bit if it's done right, but a 16/32/64-bit OS would just be
> impossible to maintain for very long
>
I would then have to complain that I am infact still running some amount of
16 bit software on windows...
I will state that I think it is possible that basic support for 16 bit apps
will exist for quite a while, just like dos support still exists now.
it is quite possible though that both 16 bit and 32 bit code could be
supported by a kind of "emulation layer" (like 16 bit and dos stuff is
now...).

of course, they are apps that if I really needed to I could probably write
myself, but for now it is unneeded...

> > --
> > bye
> > Alessandro Cantatore
> > email reply to: acantatore (at: tin.it)
> >
>
>
>
> --
> Don "Freiheit" Eitner
> Hobby eComStation & OS/2 developer
> http://freiheit.syntheticdimension.net


0
cr88192
1/24/2004 9:33:34 AM
This brings up an interesting issue.  I know the Athlon 64 can run 64-
bit plus 32-bit in "compatibility mode" but does it also support 16-bit 
at the same time, or would it have to be done with emulation?

> I would then have to complain that I am infact still running some
> amount of 16 bit software on windows...
> I will state that I think it is possible that basic support for 16
> bit apps will exist for quite a while, just like dos support still
> exists now. it is quite possible though that both 16 bit and 32 bit
> code could be supported by a kind of "emulation layer" (like 16 bit
> and dos stuff is now...).

-- 
Don "Freiheit" Eitner
Hobby eComStation & OS/2 developer
http://freiheit.syntheticdimension.net
0
Don
1/24/2004 10:50:21 AM
"Don Eitner" <freiheit@syntheticdimension-nospam.net> wrote in message
news:Xns9479E761F71A2freiheitsyntheticdim@199.45.49.11...
> No, because before you can gain the benefits of 64-bit computing, you
> need to drop the 16-bit code.  A pure 32-bit OS could be better than a
> hybrid 32/64-bit if it's done right, but a 16/32/64-bit OS would just be
> impossible to maintain for very long

OS/2 _still_ contains 16-bit code? Wow. Why?

-- 
Tim Robinson (MVP, Windows SDK)
http://www.themobius.co.uk/


0
Tim
1/24/2004 11:54:30 AM
On Sat, 24 Jan 2004 06:12:39 GMT, Alessandro Cantatore wrote:

>there is an interesting article with benchmarks regarding this subject:=

>
> <http://www.osnews.com/story.php?news_id=3D5768>
>
>BTW I think that lack of 64 bit is not a real problem for OS/2-eCS...
>(or not the main problem)

What I would find interesting for OS/2: Would there in theory be a
way to write certain "64-bit modules" or something on a current OS/2
system with, say, an Athlon 64 bit processor? I mean something like
the strange tricks that made (and make) it possible to run
applications in "upper memory" above 1MB on a DOS system, even
switching to "protected mode" etc.

Not that this is very elegant, but it would allow to make use of
64-bit capabilities for certain applications where it makes sense,
without rewriting the whole system (which will probably never happen
anyway...).

In short: This is a question for the CPU specialists here! (My own
knowledge is "limited" to "higher languages" like C++ etc.)

Greetings,
Cornelis
--
Cornelis Bockem=FChl, Basel, Switzerland
e-mail: cbockem AT tiscalinet DOT ch
(use this instead of antispam reply address)



0
Cornelis
1/24/2004 1:39:11 PM
TR> OS/2 _still_ contains 16-bit code? Wow. 

You'd be less surprised if you had followed the discussion that you yourself
started about Intel OS/2, some ten days ago.  (-:

TR> Why?

For the complex set of reasons already discussed.
0
Jonathan
1/24/2004 2:16:06 PM
Cornelis Bockemuehl wrote:
> On Sat, 24 Jan 2004 06:12:39 GMT, Alessandro Cantatore wrote:
> 
> 
>>there is an interesting article with benchmarks regarding this subject:
>>
>><http://www.osnews.com/story.php?news_id=5768>
>>
>>BTW I think that lack of 64 bit is not a real problem for OS/2-eCS...
>>(or not the main problem)
> 
> What I would find interesting for OS/2: Would there in theory be a
> way to write certain "64-bit modules" or something on a current OS/2
> system with, say, an Athlon 64 bit processor?

There's no guarantee that your registers will be preserved when the 
32-bit kernel switches contexts out from under you.  The kernel must be 
made aware of the entire state of the processor, and a 32-bit x86 kernel 
would not be.

0
Marty
1/24/2004 4:45:33 PM
"Jonathan de Boyne Pollard" <J.deBoynePollard@Tesco.NET> wrote in message
news:40127E26.9ECFFB4C@Tesco.NET...
> TR> OS/2 _still_ contains 16-bit code? Wow.
>
> You'd be less surprised if you had followed the discussion that you
yourself
> started about Intel OS/2, some ten days ago.  (-:

Apologies for not reading the 50 new posts each day split across three or
four subthreads.

> TR> Why?
>
> For the complex set of reasons already discussed.

I'll print out the latest dicussions and read them later.

Before I do that, or maybe to save me the trouble, I wonder if somebody
could summarise the reasons behind OS/2 still relying on 16-bit in 2004?

-- 
Tim Robinson (MVP, Windows SDK)
http://www.themobius.co.uk/


0
Tim
1/24/2004 4:55:13 PM
Sir:

Tim Robinson wrote:
> "Don Eitner" <freiheit@syntheticdimension-nospam.net> wrote in message
> news:Xns9479E761F71A2freiheitsyntheticdim@199.45.49.11...
> 
>>No, because before you can gain the benefits of 64-bit computing, you
>>need to drop the 16-bit code.  A pure 32-bit OS could be better than a
>>hybrid 32/64-bit if it's done right, but a 16/32/64-bit OS would just be
>>impossible to maintain for very long
> 
> 
> OS/2 _still_ contains 16-bit code? Wow. Why?
> 
We posted this earlier in this thread.  It is because there is no cost 
to benefit for the end user to be gained by using 32-bit code.  Thus, 
IBM chose to not spend the money.  The old 16-bit code ran as fast as 
32-bit code under the 386, and newer CPUs have made the point moot 
anyway.  Since the Athlon64 does run OS/2, there is no demand to convert 
it to 64-bit (thou there is a demand to fix the APM and TESTCFG drivers).
-- 
Bill
Thanks a Million!

0
William
1/24/2004 4:57:30 PM
Don Eitner wrote:
> This brings up an interesting issue.  I know the Athlon 64 can run 64-
> bit plus 32-bit in "compatibility mode" but does it also support 16-bit 
> at the same time, or would it have to be done with emulation?

In "long mode" there is no processor support for legacy operation modes 
(real, 16-bit protected and virtual x86). An emulation is required.

Ciao,
    Dani

0
Daniela
1/24/2004 5:09:34 PM
Cornelis Bockemuehl wrote:
> What I would find interesting for OS/2: Would there in theory be a
> way to write certain "64-bit modules" or something on a current OS/2
> system with, say, an Athlon 64 bit processor? I mean something like
> the strange tricks that made (and make) it possible to run
> applications in "upper memory" above 1MB on a DOS system, even
> switching to "protected mode" etc.

Something like that is impossible on an Athlon64. Several prereqisites 
have to be honoured before a process may take advantage of the 64 bit 
architectural extensions:

1) a clean, all 64-bit, flat model (without segmentation) implementation 
of *all* code running in kernel space (kernel, drivers, ...)

2) a clean, 64-bit or 32-bit implementation of all OS/2 components 
running in user space without a single bit of legacy stuff.

To fullfill both of these you are no longer talking about an OS/2 as we 
know it today.

Ciao,
   Dani

0
Daniela
1/24/2004 5:22:58 PM
Sir:

Marty wrote:
> Cornelis Bockemuehl wrote:
> 
>> On Sat, 24 Jan 2004 06:12:39 GMT, Alessandro Cantatore wrote:
>>
>>
>>> there is an interesting article with benchmarks regarding this subject:
>>>
>>> <http://www.osnews.com/story.php?news_id=5768>
>>>
>>> BTW I think that lack of 64 bit is not a real problem for OS/2-eCS...
>>> (or not the main problem)
>>
>>
>> What I would find interesting for OS/2: Would there in theory be a
>> way to write certain "64-bit modules" or something on a current OS/2
>> system with, say, an Athlon 64 bit processor?
> 
> 
> There's no guarantee that your registers will be preserved when the 
> 32-bit kernel switches contexts out from under you.  The kernel must be 
> made aware of the entire state of the processor, and a 32-bit x86 kernel 
> would not be.
> 
My understanding is that AMD designed the Athlon64's compatibility 
32/16-bit mode to be a 32-bit processor.  Thus would not show any 
registers/state that the 32-bit kernel could fail to process.  This is 
no different than the 386 runing in 286 mode.  I am ignoring the hooks 
for mode switching that the older kernel would not know existed.
-- 
Bill
Thanks a Million!

0
William
1/24/2004 5:27:28 PM
[A complimentary Cc of this posting was sent to
William L. Hartzell
<wlhartzell@comcast.net>], who wrote in article <c1.2b5.2q167Y$1Or@12-237-213-129.client.attbi.com>:
> > There's no guarantee that your registers will be preserved when the 
> > 32-bit kernel switches contexts out from under you.  The kernel must be 
> > made aware of the entire state of the processor, and a 32-bit x86 kernel 
> > would not be.

> My understanding is that AMD designed the Athlon64's compatibility 
> 32/16-bit mode to be a 32-bit processor.  Thus would not show any 
> registers/state that the 32-bit kernel could fail to process.  This is 
> no different than the 386 runing in 286 mode.  I am ignoring the hooks 
> for mode switching that the older kernel would not know existed.

Irrelevant.  This argument might work if you want to run at most one
64-bit application at a time.  But the moment you need to switch
between two 64-bit applications, you need support from the kernel.

Yours,
Ilya
0
Ilya
1/24/2004 6:01:44 PM
"William L. Hartzell" <wlhartzell@comcast.net> wrote in message
news:c1.2b5.2q15Nc$1Op@12-237-213-129.client.attbi.com...
> > OS/2 _still_ contains 16-bit code? Wow. Why?
> >
> We posted this earlier in this thread.  It is because there is no cost
> to benefit for the end user to be gained by using 32-bit code.  Thus,
> IBM chose to not spend the money.  The old 16-bit code ran as fast as
> 32-bit code under the 386, and newer CPUs have made the point moot
> anyway.  Since the Athlon64 does run OS/2, there is no demand to convert
> it to 64-bit (thou there is a demand to fix the APM and TESTCFG drivers).

I recall reading about the 512MB address space limit imposed by selector
tiling, to let 16-bit code access the same memory as 32-bit code.

Does the application programmer need to be aware of which APIs are
implemented using 16-bit code, and only pass sub-512MB buffers to them? If
so, isn't there a case for making everything 32-bit?

I know that there's a similar situation with Win9x, where KERNEL, USER and
GDI are still 16-bit, and thunks are used to interface 32-bit apps with
16-bit user-mode code. Although Win9x's problems are said to stem from this
mix of 16-bit code, presumably the 16-bit code in OS/2 doesn't affect it to
the same extent: 16-bit OS/2 was already a 'better' OS than 16-bit DOS plus
16-bit Windows 3.x.

-- 
Tim Robinson (MVP, Windows SDK)
http://www.themobius.co.uk/


0
Tim
1/24/2004 6:27:16 PM
Daniela Engert wrote:
> Don Eitner wrote:
> 
>> This brings up an interesting issue.  I know the Athlon 64 can run 64-
>> bit plus 32-bit in "compatibility mode" but does it also support 
>> 16-bit at the same time, or would it have to be done with emulation?
> 
> 
> In "long mode" there is no processor support for legacy operation modes 
> (real, 16-bit protected and virtual x86). An emulation is required.

In Long Mode, the x86-64 CPU runs 16-bit code in a 16-bit compatibility 
sub-mode without recompilation.

 From the AMD docs (AMD64 Architecture Programmer's Manual Volume 1:
Application Programming Publication No. 24592 Revision Date 3.09
September 2003):

"In compatibility mode, legacy 16-bit and 32-bit applications run
   using legacy x86 protected-mode segmentation semantics. The
   16-bit or 32-bit effective addresses generated by programs are
   combined with their segments to produce 32-bit virtual (linear)
   addresses that are zero-extended to a maximum of 64 bits. The
   paging that follows is the same long-mode paging function used
   in 64-bit mode. It translates the virtual addresses into physical
   addresses. The combination of segment selector and effective
   address is also called a logical address or far pointer. The virtual
   address is also called the linear address."

Note that both the 'compatibility' mode and the '64-bit' modes referred to
there are sub-modes of Long Mode.


-- 
Posted with OS/2 Warp 4.52
and IBM Web Browser v2.0.2

0
David
1/24/2004 6:45:52 PM
David T. Johnson wrote:
> Daniela Engert wrote:
> 
>> Don Eitner wrote:
>>
>>> This brings up an interesting issue.  I know the Athlon 64 can run 64-
>>> bit plus 32-bit in "compatibility mode" but does it also support 
>>> 16-bit at the same time, or would it have to be done with emulation?
>>
>> In "long mode" there is no processor support for legacy operation 
>> modes (real, 16-bit protected and virtual x86). An emulation is required.
> 
> In Long Mode, the x86-64 CPU runs 16-bit code in a 16-bit compatibility 
> sub-mode without recompilation.
> 
>  From the AMD docs (AMD64 Architecture Programmer's Manual Volume 1:
> Application Programming Publication No. 24592 Revision Date 3.09
> September 2003):
> 
> "In compatibility mode, legacy 16-bit and 32-bit applications run
>   using legacy x86 protected-mode segmentation semantics. The
>   16-bit or 32-bit effective addresses generated by programs are
>   combined with their segments to produce 32-bit virtual (linear)
>   addresses that are zero-extended to a maximum of 64 bits.

This makes things even worse.  Now, not only will 64-bit programs not 
have their registers saved and restored properly, but even 32-bit 
programs will clobber the portions of the registers that are not saved!

> Note that both the 'compatibility' mode and the '64-bit' modes referred to
> there are sub-modes of Long Mode.

And can you execute 64-bit instructions in "compatibility" mode?  How 
about executing 16-bit instructions in "64-bit" mode?  It doesn't matter 
if they share a common parent mode if the two features that we want to 
interoperate are mutually exclusive.

0
Marty
1/24/2004 7:01:47 PM
Tim Robinson wrote:

> Before I do that, or maybe to save me the trouble, I wonder if somebody
> could summarise the reasons behind OS/2 still relying on 16-bit in 2004?
> 
  Don't fix what ain't broke.

0
Michal
1/24/2004 7:07:00 PM
"Don Eitner" <freiheit@syntheticdimension-nospam.net> wrote in message
news:Xns947A1CE38124Dfreiheitsyntheticdim@199.45.49.11...
> This brings up an interesting issue.  I know the Athlon 64 can run 64-
> bit plus 32-bit in "compatibility mode" but does it also support 16-bit
> at the same time, or would it have to be done with emulation?
>
I am not sure on this.
emulation would be tolerable for older software, after all, it wasn't
exactly designed for blazingly fast computers...
assumably, basic emulation could even be done by a userspace app if need be,
but in the case of windows any such emulator would likely be built into the
os...

> > I would then have to complain that I am infact still running some
> > amount of 16 bit software on windows...
> > I will state that I think it is possible that basic support for 16
> > bit apps will exist for quite a while, just like dos support still
> > exists now. it is quite possible though that both 16 bit and 32 bit
> > code could be supported by a kind of "emulation layer" (like 16 bit
> > and dos stuff is now...).
>
> --
> Don "Freiheit" Eitner
> Hobby eComStation & OS/2 developer
> http://freiheit.syntheticdimension.net


0
cr88192
1/24/2004 7:49:06 PM
"Marty" <mamodeo@stny.rr.com> wrote in message
news:vizQb.42476$Fe1.37593@twister.nyroc.rr.com...
> David T. Johnson wrote:
> > Daniela Engert wrote:
> >
> >> Don Eitner wrote:
> >>
> >>> This brings up an interesting issue.  I know the Athlon 64 can run 64-
> >>> bit plus 32-bit in "compatibility mode" but does it also support
> >>> 16-bit at the same time, or would it have to be done with emulation?
> >>
> >> In "long mode" there is no processor support for legacy operation
> >> modes (real, 16-bit protected and virtual x86). An emulation is
required.
> >
> > In Long Mode, the x86-64 CPU runs 16-bit code in a 16-bit compatibility
> > sub-mode without recompilation.
> >
> >  From the AMD docs (AMD64 Architecture Programmer's Manual Volume 1:
> > Application Programming Publication No. 24592 Revision Date 3.09
> > September 2003):
> >
> > "In compatibility mode, legacy 16-bit and 32-bit applications run
> >   using legacy x86 protected-mode segmentation semantics. The
> >   16-bit or 32-bit effective addresses generated by programs are
> >   combined with their segments to produce 32-bit virtual (linear)
> >   addresses that are zero-extended to a maximum of 64 bits.
>
> This makes things even worse.  Now, not only will 64-bit programs not
> have their registers saved and restored properly, but even 32-bit
> programs will clobber the portions of the registers that are not saved!
>
> > Note that both the 'compatibility' mode and the '64-bit' modes referred
to
> > there are sub-modes of Long Mode.
>
> And can you execute 64-bit instructions in "compatibility" mode?  How
> about executing 16-bit instructions in "64-bit" mode?  It doesn't matter
> if they share a common parent mode if the two features that we want to
> interoperate are mutually exclusive.
>

no.. you can only execute 64-bit instructions in a 64-bit code segment....
when you load CS with a selector for a 64-bit code segment, you are then in
64-bit mode... no longer in compatibility...

though... i've been having to go over a few things in their docs several
times... (i can't wait till i can actually purchase an x86-64 system to test
this stuff)..... while the docs say that 16- and 32- bit programs can be
executed in compatibility mode (submode of long mode), another place in the
docs show that information as untrue.... (give me a few hours.. i'll compile
the info)...




0
Bx
1/24/2004 8:39:27 PM
Here in comp.os.os2.programmer.misc,
"Tim Robinson" <tim.at.gaat.freeserve.co.uk@invalid.com> spake unto us, saying:

>"Jonathan de Boyne Pollard" <J.deBoynePollard@Tesco.NET> wrote
>> TR> OS/2 _still_ contains 16-bit code? Wow.
>>
>> You'd be less surprised if you had followed the discussion that you
>> yourself started about Intel OS/2, some ten days ago.  (-:
>
>Apologies for not reading the 50 new posts each day split across three or
>four subthreads.

If you used a real newsreader, perhaps the above task wouldn't be that
difficult for you.  :-)

>Before I do that, or maybe to save me the trouble, I wonder if somebody
>could summarise the reasons behind OS/2 still relying on 16-bit in 2004?

There isn't really a performance penalty (or there is very little) in
the places that 16-bit code is still used.

Because of that, there isn't much justification to rewrite the code.

-- 
 -Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
  OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
     Applications analyst/designer/developer (14 yrs) seeking employment.
              See web site above for resume/CV and background.
0
rsteiner
1/24/2004 9:07:38 PM
"Richard Steiner" <rsteiner@visi.com> wrote in message
news:a6tEApHpv2xR092yn@visi.com...
> There isn't really a performance penalty (or there is very little) in
> the places that 16-bit code is still used.
>
> Because of that, there isn't much justification to rewrite the code.

Fair enough. It ain't broke.

-- 
Tim Robinson (MVP, Windows SDK)
http://www.themobius.co.uk/


0
Tim
1/24/2004 10:07:16 PM
"Ilya Zakharevich" <nospam-abuse@ilyaz.org> wrote in message
news:buubu8$i60$1@agate.berkeley.edu...
> [A complimentary Cc of this posting was sent to
> William L. Hartzell
> <wlhartzell@comcast.net>], who wrote in article
<c1.2b5.2q167Y$1Or@12-237-213-129.client.attbi.com>:
> > > There's no guarantee that your registers will be preserved when the
> > > 32-bit kernel switches contexts out from under you.  The kernel must
be
> > > made aware of the entire state of the processor, and a 32-bit x86
kernel
> > > would not be.
>
> > My understanding is that AMD designed the Athlon64's compatibility
> > 32/16-bit mode to be a 32-bit processor.  Thus would not show any
> > registers/state that the 32-bit kernel could fail to process.  This is
> > no different than the 386 runing in 286 mode.  I am ignoring the hooks
> > for mode switching that the older kernel would not know existed.
>
> Irrelevant.  This argument might work if you want to run at most one
> 64-bit application at a time.  But the moment you need to switch
> between two 64-bit applications, you need support from the kernel.

the point is tho, you cant run in long mode (64bits) mode without the kernel
knowing about it anyway.
in much the same way as you cant run in protected mode on IA32 without
knowing it---> the kernel must put it into long mode, hence it must know
about it.
prior to being in long mode, it behaves like a standard IA32 processor, with
all its limitations

thus if running 64bit apps, the kernel would know it were on a 64bit
processor and be designed for it, hence this problem of register clobbering
etc would not exist as the kernel knows better (hopefully)

on the opposite, if running a 32bit kernel (eg windows/linux IA32) you would
be in protected (32bit) mode NOT long mode, so as is stated above, there
would be no problem as it "would not show any registers/state that the
32-bit kernel could fail to process.  "

think 16bit windows 3.1 running on a 32bit machine (in 16bit protected
mode).

Ben


>
> Yours,
> Ilya


0
BGainey
1/24/2004 11:15:58 PM
On Sat, 24 Jan 2004 17:27:28 GMT, William L. Hartzell wrote:

>Sir:
>
>Marty wrote:
>> Cornelis Bockemuehl wrote:
>> 
>>> On Sat, 24 Jan 2004 06:12:39 GMT, Alessandro Cantatore wrote:
>>>
>>>
>>>> there is an interesting article with benchmarks regarding this subject:
>>>>
>>>> <http://www.osnews.com/story.php?news_id=5768>
>>>>
>>>> BTW I think that lack of 64 bit is not a real problem for OS/2-eCS...
>>>> (or not the main problem)
>>>
>>>
>>> What I would find interesting for OS/2: Would there in theory be a
>>> way to write certain "64-bit modules" or something on a current OS/2
>>> system with, say, an Athlon 64 bit processor?
>> 
>> 
>> There's no guarantee that your registers will be preserved when the 
>> 32-bit kernel switches contexts out from under you.  The kernel must be 
>> made aware of the entire state of the processor, and a 32-bit x86 kernel 
>> would not be.
>> 
>My understanding is that AMD designed the Athlon64's compatibility 
>32/16-bit mode to be a 32-bit processor.  Thus would not show any 
>registers/state that the 32-bit kernel could fail to process.  This is 
>no different than the 386 runing in 286 mode.  I am ignoring the hooks 
>for mode switching that the older kernel would not know existed.

That would only be relevant in a single-task system.  In a multi-tasking
system, the kernel must save and restore the register states when pre-empting
and granting time slices.  A 32-bit kernel would not save and restore 64-bit
registers, so 64-bit apps would never have a valid set of registers.  It
would require hooks into the scheduling of the kernel, which would be awfully
difficult for an add-on hack to do without killing performance horribly.


--
 - Mike

Remove 'spambegone.net' and reverse to send e-mail.


0
Mike
1/24/2004 11:50:08 PM
"cr88192" <cr88192@hotmail.com> wrote
> "Don Eitner" <freiheit@syntheticdimension-nospam.net> wrote
> > This brings up an interesting issue.  I know the Athlon 64 can run 64-
> > bit plus 32-bit in "compatibility mode" but does it also support 16-bit
> > at the same time, or would it have to be done with emulation?
> I am not sure on this.
> emulation would be tolerable for older software, after all, it wasn't
> exactly designed for blazingly fast computers...
> assumably, basic emulation could even be done by a userspace app if need be,
> but in the case of windows any such emulator would likely be built into the
> os...

 In compatibility mode, a new segment size is added, so the new segment
 types are 16/32/64/reserved. In a 64 bit segment 8 and 64 bit wide data
 is the default and prefixes are needed to access 16 and 32 bit wide
 data. (just like today for 16 bit from a 32 bit segment) The address
 limitation still exist, but there is a hack to extend it. You can run a
 v86 task along with 16/32/64 bit pmode tasks, and they can call into
 each other, or a program can use mixed data/code/stack segments. The
 64 bit flag is hacked into the segment descriptor structure. A program
 running in a 64 bit code segment can access the extended registers.

 In native mode, there is no segmentation or any emulation support.

  Viktor

ps:
 Adding AMD64 support for an existing os means adding a new segment type,
 and its comparable to adding mmx or sse support. Even the apis can stay
 32 bit, but the app will run in 64 bit mode.
0
nospam777
1/25/2004 1:31:34 AM
"KVP" <nospam777@freemail.hu> wrote in message
news:9f459d85.0401241731.74b51cf2@posting.google.com...
> "cr88192" <cr88192@hotmail.com> wrote
> > "Don Eitner" <freiheit@syntheticdimension-nospam.net> wrote
> > > This brings up an interesting issue.  I know the Athlon 64 can run 64-
> > > bit plus 32-bit in "compatibility mode" but does it also support
16-bit
> > > at the same time, or would it have to be done with emulation?
> > I am not sure on this.
> > emulation would be tolerable for older software, after all, it wasn't
> > exactly designed for blazingly fast computers...
> > assumably, basic emulation could even be done by a userspace app if need
be,
> > but in the case of windows any such emulator would likely be built into
the
> > os...
>
>  In compatibility mode, a new segment size is added, so the new segment
>  types are 16/32/64/reserved. In a 64 bit segment 8 and 64 bit wide data
>  is the default and prefixes are needed to access 16 and 32 bit wide
>  data. (just like today for 16 bit from a 32 bit segment) The address
>  limitation still exist, but there is a hack to extend it. You can run a
>  v86 task along with 16/32/64 bit pmode tasks, and they can call into
>  each other, or a program can use mixed data/code/stack segments. The
>  64 bit flag is hacked into the segment descriptor structure. A program
>  running in a 64 bit code segment can access the extended registers.
>
ok.

>  In native mode, there is no segmentation or any emulation support.
>
people were making it sound like it was more of a problem than that.

by "emulation", I had meant they could actually be using a software based
emulator and have ways to interface with the outside system (eg: doing
certain things will indicate to the emulator that some call is requested or
such).

or, also possible, could be to "recompile" the app for the new architecture,
eg:
info is retained mapping old instruction addresses to new ones;
a buffer is used to hold the "recompiled" code;
trying to jump a not yet compiled address causes more code to be pulled from
the image and recompiled;
....
actually, assuming the code behaves in a straightforward manner, it should
be possible to do this statically as well (this may be problematic though,
eg, fixing up addresses, eg, in the case of function pointers...). it may be
possible to work around this with some dynamic checks (eg: tagging values as
integers or code pointers, remapping between integers and code pointers when
calls/returns/jumps/... or stores into integers are done, but this could
have notable performance costs).
any kind of self modifying code could possibly break this as well though.

a more "general purpose" cpu emulator (one that works sequentially and does
not use "recompiled" code) could be a lot more stable/flexible, but would
likely run a bit slower...

I don't know, all this is outside my area of expertise...

if the cpu can still use 16 bit code along with 64 bit code then this is
less of a big deal...

>   Viktor
>
> ps:
>  Adding AMD64 support for an existing os means adding a new segment type,
>  and its comparable to adding mmx or sse support. Even the apis can stay
>  32 bit, but the app will run in 64 bit mode.
ok, cool...



0
cr88192
1/25/2004 2:43:19 AM
KVP wrote:
> ps:
>  Adding AMD64 support for an existing os means adding a new segment type,
>  and its comparable to adding mmx or sse support. Even the apis can stay
>  32 bit, but the app will run in 64 bit mode.

Which works great until you want to run two such apps at the same time, yes?

0
Marty
1/25/2004 4:17:38 AM
Bx.C wrote:
> "Marty" <mamodeo@stny.rr.com> wrote in message
> news:vizQb.42476$Fe1.37593@twister.nyroc.rr.com...
> 
>>David T. Johnson wrote:
>>
>>>Daniela Engert wrote:
>>>
>>>
>>>>Don Eitner wrote:
>>>>
>>>>
>>>>>This brings up an interesting issue.  I know the Athlon 64 can run 64-
>>>>>bit plus 32-bit in "compatibility mode" but does it also support
>>>>>16-bit at the same time, or would it have to be done with emulation?
>>>>
>>>>In "long mode" there is no processor support for legacy operation
>>>>modes (real, 16-bit protected and virtual x86). An emulation is
> 
> required.
> 
>>>In Long Mode, the x86-64 CPU runs 16-bit code in a 16-bit compatibility
>>>sub-mode without recompilation.
>>>
>>> From the AMD docs (AMD64 Architecture Programmer's Manual Volume 1:
>>>Application Programming Publication No. 24592 Revision Date 3.09
>>>September 2003):
>>>
>>>"In compatibility mode, legacy 16-bit and 32-bit applications run
>>>  using legacy x86 protected-mode segmentation semantics. The
>>>  16-bit or 32-bit effective addresses generated by programs are
>>>  combined with their segments to produce 32-bit virtual (linear)
>>>  addresses that are zero-extended to a maximum of 64 bits.
>>
>>This makes things even worse.  Now, not only will 64-bit programs not
>>have their registers saved and restored properly, but even 32-bit
>>programs will clobber the portions of the registers that are not saved!
>>
>>
>>>Note that both the 'compatibility' mode and the '64-bit' modes referred
> 
> to
> 
>>>there are sub-modes of Long Mode.
>>
>>And can you execute 64-bit instructions in "compatibility" mode?  How
>>about executing 16-bit instructions in "64-bit" mode?  It doesn't matter
>>if they share a common parent mode if the two features that we want to
>>interoperate are mutually exclusive.
>>
> 
> 
> no.. you can only execute 64-bit instructions in a 64-bit code segment....
> when you load CS with a selector for a 64-bit code segment, you are then in
> 64-bit mode... no longer in compatibility...

That's exactly how it looks to me as well.  The x86-64 CPUs can run in 
either 'long mode' (64-bit) or 'legacy mode' (32-bit) and the mode is 
controlled by a 'global control bit' called LMA.

When LMA is disabled, the processor operates as a standard x86 processor 
and is compatible with all existing 16 and 32-bit operating systems.

When LMA is enabled, the processor will still run 16-bit and 32-bit 
applications in one of two compatibility 'sub modes' that are activated 
with two flags (the existing "D" bit that controls the size of operands 
and an "L" bit that was previously unused) in the code segment 
descriptor.  The L bit must be enabled to identify an application as 
'64-bit'.  If the D bit is enabled, the application runs in 32-bit 
compatibility mode, although the processor is still in long mode.


> 
> though... i've been having to go over a few things in their docs several
> times... (i can't wait till i can actually purchase an x86-64 system to test
> this stuff)..... while the docs say that 16- and 32- bit programs can be
> executed in compatibility mode (submode of long mode),

I think that's correct.


> another place in the
> docs show that information as untrue....

I suspect that is an error.  I would be interested in a reference to it.

> (give me a few hours.. i'll compile
> the info)...
> 
> 
> 
> 


-- 
Posted with OS/2 Warp 4.52
and IBM Web Browser v2.0.2 

0
David
1/25/2004 4:39:32 AM
> > >>> This brings up an interesting issue.  I know the Athlon 64 can run
64-
> > >>> bit plus 32-bit in "compatibility mode" but does it also support
> > >>> 16-bit at the same time, or would it have to be done with emulation?
> > >>
> > >> In "long mode" there is no processor support for legacy operation
> > >> modes (real, 16-bit protected and virtual x86). An emulation is
> required.
> > >
> > > In Long Mode, the x86-64 CPU runs 16-bit code in a 16-bit
compatibility
> > > sub-mode without recompilation.
> > >
> > >  From the AMD docs (AMD64 Architecture Programmer's Manual Volume 1:
> > > Application Programming Publication No. 24592 Revision Date 3.09
> > > September 2003):
> > >
> > > "In compatibility mode, legacy 16-bit and 32-bit applications run
> > >   using legacy x86 protected-mode segmentation semantics. The
> > >   16-bit or 32-bit effective addresses generated by programs are
> > >   combined with their segments to produce 32-bit virtual (linear)
> > >   addresses that are zero-extended to a maximum of 64 bits.
> >
> > This makes things even worse.  Now, not only will 64-bit programs not
> > have their registers saved and restored properly, but even 32-bit
> > programs will clobber the portions of the registers that are not saved!
> >
> > > Note that both the 'compatibility' mode and the '64-bit' modes
referred
> to
> > > there are sub-modes of Long Mode.
> >
> > And can you execute 64-bit instructions in "compatibility" mode?  How
> > about executing 16-bit instructions in "64-bit" mode?  It doesn't matter
> > if they share a common parent mode if the two features that we want to
> > interoperate are mutually exclusive.
> >
>
> no.. you can only execute 64-bit instructions in a 64-bit code segment....
> when you load CS with a selector for a 64-bit code segment, you are then
in
> 64-bit mode... no longer in compatibility...
>
> though... i've been having to go over a few things in their docs several
> times... (i can't wait till i can actually purchase an x86-64 system to
test
> this stuff)..... while the docs say that 16- and 32- bit programs can be
> executed in compatibility mode (submode of long mode), another place in
the
> docs show that information as untrue.... (give me a few hours.. i'll
compile
> the info)...
>


well it's been about 10 hours since I've posted this and my own newsserver
hasn't shown it yet... so i'm posting it again..... sorry if this is a
repost for ya'll....


ok... here we go...

in Long Mode.... compatibility mode supports 16-bit protected mode code
segments and 32-bit protected mode code segments.... no v86 under long
mode.... also, there's two more important bits of info to know for Long
mode.... all interrupts are to go to 64-bit code segments.....  and there's
no hardware task swapping... you have a single 64-bit TSS.... (one good
thing to know... we do have the option for separate stack pointers for each
interrupt... so we can still handle stack-based problems via the doublefault
handler)....

now... the reason i'd assume there's no hardware task swapping, is because
we all know that software-based task swapping is faster anyway....  dunno
why that is, considering the hardware in the CPU has access direct access to
its own registers... it should be able to do it faster than a list of
software instructions..... but for some reason, they haven't been able to do
so...... but anyways....

Long mode is a very terrible creature when it tries dealing with its older
sister, legacy mode....basically, you have to disable paging in legacy mode
(CR0.PG=0)... set the long mode enable bit (LME) in the
extended-feature-enable register (EFER... MSR# C000_0080h).... re-enable
paging (CR0.PG=1)... (of course, paging under long mode isn't exactly the
same).... as soon as you re-enable paging.... the processor will set the
long mode activated flag (EFER.LMA)...  now, with EFER.LMA=1.... you can
still work with 16-bit code segments and 32-bit code segments.... but system
descriptors use the 64-bit form (even while you're in compatibility mode...
the only exception to this... in compatibility mode, the LDT descriptor is a
32-bit LDT).......   you go into 64-bit mode when you load CS with a
selector of a descriptor that has bit 21 (now called the L bit... previously
unused?) set to 1.... (and bit 22, the D bit...must be set to 0.... L=1, D=1
is reserved for future use)....

anyways... yes i can see it still being possible to run v86 mode on a 64-bit
OS.... but that'll be a very klunky hack..... you can forget about
pre-emptive multitasking w/ mixed v86 and 64-bit.... this is because you
have to disable paging before swapping between long mode and legacy
mode,.... then re-enable paging, if desired.....   with that much work, you
might as well put 64-bit applications on hold (along w/ any related 32-bit
code segments or 16-bit code segments that go with that 64-bit app) while
you work w/ v86 / pm16 / pm32...  then when the user doesn't need a v86
session any longer.... ask the user if he/she is planning in using another
v86 session, or if it would be okay for you to go back into long mode and
allow 64-bit programs to continue running again....

anyways... i can see it possible to support both v86 mode and 64-bit
mode.... but..... it's a real-time exclusive support.... you're either
allowing v86 threads to run, or 64-bit threads to run... but both can't have
a non-zero timeslice value at any one point in time, due to major overhead
involved in swapping between the two....







0
Bx
1/25/2004 11:01:21 AM
Sir:

Ilya Zakharevich wrote:
> [A complimentary Cc of this posting was sent to
> William L. Hartzell
> <wlhartzell@comcast.net>], who wrote in article <c1.2b5.2q167Y$1Or@12-237-213-129.client.attbi.com>:
> 
>>>There's no guarantee that your registers will be preserved when the 
>>>32-bit kernel switches contexts out from under you.  The kernel must be 
>>>made aware of the entire state of the processor, and a 32-bit x86 kernel 
>>>would not be.
> 
> 
>>My understanding is that AMD designed the Athlon64's compatibility 
>>32/16-bit mode to be a 32-bit processor.  Thus would not show any 
>>registers/state that the 32-bit kernel could fail to process.  This is 
>>no different than the 386 runing in 286 mode.  I am ignoring the hooks 
>>for mode switching that the older kernel would not know existed.
> 
> 
> Irrelevant.  This argument might work if you want to run at most one
> 64-bit application at a time.  But the moment you need to switch
> between two 64-bit applications, you need support from the kernel.
> 

The point of it is OS/2 will not allow you to run a 64-bit application
even if you wanted to do so, assuming that 64-bit operations was
possible while having the machine in 386 mode.  Don't forget that there
are two incompatible modes for the Athlon64 machine: 32/64-bit mode, and
386 mode.  OS/2 will not run in the 32/64-bit mode as it requires 16-bit
  operations to boot.
-- 
Bill
Thanks a Million!

0
William
1/25/2004 11:27:12 AM
Sir:

Mike Ruskai wrote:
> On Sat, 24 Jan 2004 17:27:28 GMT, William L. Hartzell wrote:
> 
> 
>>Sir:
>>
>>Marty wrote:
>>
>>>Cornelis Bockemuehl wrote:
>>>
>>>
>>>>On Sat, 24 Jan 2004 06:12:39 GMT, Alessandro Cantatore wrote:
>>>>
>>>>
>>>>
>>>>>there is an interesting article with benchmarks regarding this subject:
>>>>>
>>>>><http://www.osnews.com/story.php?news_id=5768>
>>>>>
>>>>>BTW I think that lack of 64 bit is not a real problem for OS/2-eCS...
>>>>>(or not the main problem)
>>>>
>>>>
>>>>What I would find interesting for OS/2: Would there in theory be a
>>>>way to write certain "64-bit modules" or something on a current OS/2
>>>>system with, say, an Athlon 64 bit processor?
>>>
>>>
>>>There's no guarantee that your registers will be preserved when the 
>>>32-bit kernel switches contexts out from under you.  The kernel must be 
>>>made aware of the entire state of the processor, and a 32-bit x86 kernel 
>>>would not be.
>>>
>>
>>My understanding is that AMD designed the Athlon64's compatibility 
>>32/16-bit mode to be a 32-bit processor.  Thus would not show any 
>>registers/state that the 32-bit kernel could fail to process.  This is 
>>no different than the 386 runing in 286 mode.  I am ignoring the hooks 
>>for mode switching that the older kernel would not know existed.
> 
> 
> That would only be relevant in a single-task system.  In a multi-tasking
> system, the kernel must save and restore the register states when pre-empting
> and granting time slices.  A 32-bit kernel would not save and restore 64-bit
> registers, so 64-bit apps would never have a valid set of registers.  It
> would require hooks into the scheduling of the kernel, which would be awfully
> difficult for an add-on hack to do without killing performance horribly.
> 

OH, then you are going to write the kernel routines to allow the machine 
to change its mode from the 386 mode to the 32/64-bit mode?  So tell me 
16-bit code fails under 32-bit OS/2 because the upper 16-bits are 
polluted by 16-bit code?  Your arguement fails if you stop to consider 
that the machine state does not allow the upper 32-bit to be visible to 
the kernel while in 386 mode, ever; Just as the 16-bit kernel of DOS 
does not see the 32-bit registers while in a VM.  Yes, 386 mode is a VM.
-- 
Bill
Thanks a Million!

0
William
1/25/2004 11:29:01 AM
"William L. Hartzell" <wlhartzell@comcast.net> wrote in message
news:c1.2b5.2q1Yz2$1Ot@12-237-213-129.client.attbi.com...
> Sir:
>
> Ilya Zakharevich wrote:
> > [A complimentary Cc of this posting was sent to
> > William L. Hartzell
> > <wlhartzell@comcast.net>], who wrote in article
<c1.2b5.2q167Y$1Or@12-237-213-129.client.attbi.com>:
> >
> >>>There's no guarantee that your registers will be preserved when the
> >>>32-bit kernel switches contexts out from under you.  The kernel must be
> >>>made aware of the entire state of the processor, and a 32-bit x86
kernel
> >>>would not be.
> >
> >
> >>My understanding is that AMD designed the Athlon64's compatibility
> >>32/16-bit mode to be a 32-bit processor.  Thus would not show any
> >>registers/state that the 32-bit kernel could fail to process.  This is
> >>no different than the 386 runing in 286 mode.  I am ignoring the hooks
> >>for mode switching that the older kernel would not know existed.
> >
> >
> > Irrelevant.  This argument might work if you want to run at most one
> > 64-bit application at a time.  But the moment you need to switch
> > between two 64-bit applications, you need support from the kernel.
> >
>
> The point of it is OS/2 will not allow you to run a 64-bit application
> even if you wanted to do so, assuming that 64-bit operations was
> possible while having the machine in 386 mode.  Don't forget that there
> are two incompatible modes for the Athlon64 machine: 32/64-bit mode, and
> 386 mode.  OS/2 will not run in the 32/64-bit mode as it requires 16-bit
>   operations to boot.
> --
> Bill
> Thanks a Million!
>

actually... the modes are separated as follows...

long mode, which has two submodes.. compatibility mode and 64-bit mode...
and
legacy mode, which we all know as our entire 32-bit processor

long mode's compatibility mode will not do v86 or real.... so in long mode,
you are allowed only pm16, pm32, and pm64... as i like to call them....
(that's 16-bit, 32-bit, and 64-bit protected mode code segments)....

in legacy mode, (tossing aside real mode, though)... you have v86, pm16, and
pm32....

also, with Long mode, all interrupts are to be handled as 64-bit.... so that
right there requires a little of a re-write to make the transition....

in addition... the switch from legacy to long is very klunky... once you're
in legacy protected mode, then you must disable paging (if you have enabled
it already), then set the long mode enabled bit (a bit in an MSR)... then
re-enable paging (with a set of structures that work for paging in long
mode).... with paging re-enabled, the processor will set the long mode
active bit (in that same MSR)... at THAT point, you're in long mode...

while i assume you have to reverse those steps to exit long mode... i
haven't found any reference yet in the AMD64 books as far as exiting long
mode.... so, i'm not entirely sure, but i'm assuming it's POSSIBLE (though
not quite probable that you'd want to) that you can have v86 sessions and
64-bit sessions running on the same OS... but naturally, due to all the
overhead with jumping back and forth between long and legacy... you would
definitely want to set the timeslice to 0 for v86 sessions while in long
mode, and for 64-bit apps (and any threads they have that are in 16-bit and
32-bit pmode code segments) while in legacy mode....

now as for OS/2.... well, like i said... a rewrite needs to be done so that
interrupts can be handled in long mode...

Oh.. and if ANYONE is planning on making an operating system for x86-64
processors,.. now would be a pretty good time to start putting it out there
in my opinion, since there isn't very much competition yet....


0
Bx
1/25/2004 11:51:26 AM
Sir:

Bx.C wrote:
> "William L. Hartzell" <wlhartzell@comcast.net> wrote in message
> news:c1.2b5.2q1Yz2$1Ot@12-237-213-129.client.attbi.com...
> 
>>Sir:
>>
>>Ilya Zakharevich wrote:
>>
>>>[A complimentary Cc of this posting was sent to
>>>William L. Hartzell
>>><wlhartzell@comcast.net>], who wrote in article
> 
> <c1.2b5.2q167Y$1Or@12-237-213-129.client.attbi.com>:
> 
>>>>>There's no guarantee that your registers will be preserved when the
>>>>>32-bit kernel switches contexts out from under you.  The kernel must be
>>>>>made aware of the entire state of the processor, and a 32-bit x86
> 
> kernel
> 
>>>>>would not be.
>>>
>>>
>>>>My understanding is that AMD designed the Athlon64's compatibility
>>>>32/16-bit mode to be a 32-bit processor.  Thus would not show any
>>>>registers/state that the 32-bit kernel could fail to process.  This is
>>>>no different than the 386 runing in 286 mode.  I am ignoring the hooks
>>>>for mode switching that the older kernel would not know existed.
>>>
>>>
>>>Irrelevant.  This argument might work if you want to run at most one
>>>64-bit application at a time.  But the moment you need to switch
>>>between two 64-bit applications, you need support from the kernel.
>>>
>>
>>The point of it is OS/2 will not allow you to run a 64-bit application
>>even if you wanted to do so, assuming that 64-bit operations was
>>possible while having the machine in 386 mode.  Don't forget that there
>>are two incompatible modes for the Athlon64 machine: 32/64-bit mode, and
>>386 mode.  OS/2 will not run in the 32/64-bit mode as it requires 16-bit
>>  operations to boot.
>>--
>>Bill
>>Thanks a Million!
>>
> 
> 
> actually... the modes are separated as follows...
> 
> long mode, which has two submodes.. compatibility mode and 64-bit mode...
> and
> legacy mode, which we all know as our entire 32-bit processor
> 
> long mode's compatibility mode will not do v86 or real.... so in long mode,
> you are allowed only pm16, pm32, and pm64... as i like to call them....
> (that's 16-bit, 32-bit, and 64-bit protected mode code segments)....
> 
> in legacy mode, (tossing aside real mode, though)... you have v86, pm16, and
> pm32....
> 
> also, with Long mode, all interrupts are to be handled as 64-bit.... so that
> right there requires a little of a re-write to make the transition....
> 
> in addition... the switch from legacy to long is very klunky... once you're
> in legacy protected mode, then you must disable paging (if you have enabled
> it already), then set the long mode enabled bit (a bit in an MSR)... then
> re-enable paging (with a set of structures that work for paging in long
> mode).... with paging re-enabled, the processor will set the long mode
> active bit (in that same MSR)... at THAT point, you're in long mode...
> 
> while i assume you have to reverse those steps to exit long mode... i
> haven't found any reference yet in the AMD64 books as far as exiting long
> mode.... so, i'm not entirely sure, but i'm assuming it's POSSIBLE (though
> not quite probable that you'd want to) that you can have v86 sessions and
> 64-bit sessions running on the same OS... but naturally, due to all the
> overhead with jumping back and forth between long and legacy... you would
> definitely want to set the timeslice to 0 for v86 sessions while in long
> mode, and for 64-bit apps (and any threads they have that are in 16-bit and
> 32-bit pmode code segments) while in legacy mode....
> 
> now as for OS/2.... well, like i said... a rewrite needs to be done so that
> interrupts can be handled in long mode...
> 
> Oh.. and if ANYONE is planning on making an operating system for x86-64
> processors,.. now would be a pretty good time to start putting it out there
> in my opinion, since there isn't very much competition yet....
> 
> 
The thing about 64-bit pointer and the such is a red herring as OS/2 
will boot on the Athlon64 machine.  Since it is booting there, then it 
must be in some mode that allows it to function.  From my reading of the 
documentation as you said, that cannot be any mode where 64-bit op are 
allowed.  So the question of running 64-bit code on OS/2 is moot (and 
may be differnet on Intel's machine).
-- 
Bill
Thanks a Million!

0
William
1/25/2004 12:57:13 PM
> The thing about 64-bit pointer and the such is a red herring as OS/2
> will boot on the Athlon64 machine.  Since it is booting there, then it
> must be in some mode that allows it to function.  From my reading of the
> documentation as you said, that cannot be any mode where 64-bit op are
> allowed.  So the question of running 64-bit code on OS/2 is moot (and
> may be differnet on Intel's machine).

true.. the existing version(s) of OS/2 don't have the capabilities for long
mode, so they run in legacy mode... the x86-64 processors still start out in
real-mode at boot time... lnog mode is just an extension (well, kinda) of
legacy pmode...

and also true.. you can't access the 64-bit forms of instructions in legacy
or compatibility mode... only in 64-bit mode.... (rex prefixes aren't
possible until you're in 64-bit mode... they're still defined as single byte
inc and  dec)...


0
Bx
1/25/2004 2:49:15 PM
William L. Hartzell wrote:
> Sir:
> 
> Mike Ruskai wrote:
> 
>> That would only be relevant in a single-task system.  In a multi-tasking
>> system, the kernel must save and restore the register states when 
>> pre-empting
>> and granting time slices.  A 32-bit kernel would not save and restore 
>> 64-bit
>> registers, so 64-bit apps would never have a valid set of registers.  It
>> would require hooks into the scheduling of the kernel, which would be 
>> awfully
>> difficult for an add-on hack to do without killing performance horribly.
> 
> OH, then you are going to write the kernel routines to allow the machine 
> to change its mode from the 386 mode to the 32/64-bit mode?  So tell me 
> 16-bit code fails under 32-bit OS/2 because the upper 16-bits are 
> polluted by 16-bit code?  Your arguement fails if you stop to consider 
> that the machine state does not allow the upper 32-bit to be visible to 
> the kernel while in 386 mode, ever; Just as the 16-bit kernel of DOS 
> does not see the 32-bit registers while in a VM.  Yes, 386 mode is a VM.

This was an argument against the proposed (and subsequently deemed 
impossible) hybrid mode, where the 32-bit kernel controls the show, but 
apps still have access to 64-bit instructions.  Think back to Win32S on 
Win3.1.  In that case, the kernel was modified so that the full state of 
the 386 CPU could be saved between tasks.  If this hybrid mode could 
exist, we'd have to do the same for OS/2.

But in our current case, the very fact that the upper 32 bits of the 
registers are invisible to the 32-bit kernel is what precludes the 
possibility of 64-bit applications running.

0
Marty
1/25/2004 4:49:59 PM
Bx.C wrote:
>>>>>>This brings up an interesting issue.  I know the Athlon 64 can run
> 
> 64-
> 
>>>>>>bit plus 32-bit in "compatibility mode" but does it also support
>>>>>>16-bit at the same time, or would it have to be done with emulation?
>>>>>
>>>>>In "long mode" there is no processor support for legacy operation
>>>>>modes (real, 16-bit protected and virtual x86). An emulation is
>>
>>required.
>>
>>>>In Long Mode, the x86-64 CPU runs 16-bit code in a 16-bit
> 
> compatibility
> 
>>>>sub-mode without recompilation.
>>>>
>>>> From the AMD docs (AMD64 Architecture Programmer's Manual Volume 1:
>>>>Application Programming Publication No. 24592 Revision Date 3.09
>>>>September 2003):
>>>>
>>>>"In compatibility mode, legacy 16-bit and 32-bit applications run
>>>>  using legacy x86 protected-mode segmentation semantics. The
>>>>  16-bit or 32-bit effective addresses generated by programs are
>>>>  combined with their segments to produce 32-bit virtual (linear)
>>>>  addresses that are zero-extended to a maximum of 64 bits.
>>>
>>>This makes things even worse.  Now, not only will 64-bit programs not
>>>have their registers saved and restored properly, but even 32-bit
>>>programs will clobber the portions of the registers that are not saved!
>>>
>>>
>>>>Note that both the 'compatibility' mode and the '64-bit' modes
> 
> referred
> 
>>to
>>
>>>>there are sub-modes of Long Mode.
>>>
>>>And can you execute 64-bit instructions in "compatibility" mode?  How
>>>about executing 16-bit instructions in "64-bit" mode?  It doesn't matter
>>>if they share a common parent mode if the two features that we want to
>>>interoperate are mutually exclusive.
>>>
>>
>>no.. you can only execute 64-bit instructions in a 64-bit code segment....
>>when you load CS with a selector for a 64-bit code segment, you are then
> 
> in
> 
>>64-bit mode... no longer in compatibility...
>>
>>though... i've been having to go over a few things in their docs several
>>times... (i can't wait till i can actually purchase an x86-64 system to
> 
> test
> 
>>this stuff)..... while the docs say that 16- and 32- bit programs can be
>>executed in compatibility mode (submode of long mode), another place in
> 
> the
> 
>>docs show that information as untrue.... (give me a few hours.. i'll
> 
> compile
> 
>>the info)...
>>
> 
> 
> 
> well it's been about 10 hours since I've posted this and my own newsserver
> hasn't shown it yet... so i'm posting it again..... sorry if this is a
> repost for ya'll....
> 
> 
> ok... here we go...
> 
> in Long Mode.... compatibility mode supports 16-bit protected mode code
> segments and 32-bit protected mode code segments.... no v86 under long
> mode.... also, there's two more important bits of info to know for Long
> mode.... all interrupts are to go to 64-bit code segments.....  and there's
> no hardware task swapping... you have a single 64-bit TSS.... (one good
> thing to know... we do have the option for separate stack pointers for each
> interrupt... so we can still handle stack-based problems via the doublefault
> handler)....
> 
> now... the reason i'd assume there's no hardware task swapping, is because
> we all know that software-based task swapping is faster anyway....  dunno
> why that is, considering the hardware in the CPU has access direct access to
> its own registers... it should be able to do it faster than a list of
> software instructions..... but for some reason, they haven't been able to do
> so...... but anyways....
> 
> Long mode is a very terrible creature when it tries dealing with its older
> sister, legacy mode....basically, you have to disable paging in legacy mode
> (CR0.PG=0)... set the long mode enable bit (LME) in the
> extended-feature-enable register (EFER... MSR# C000_0080h).... re-enable
> paging (CR0.PG=1)... (of course, paging under long mode isn't exactly the
> same).... as soon as you re-enable paging.... the processor will set the
> long mode activated flag (EFER.LMA)...  now, with EFER.LMA=1.... you can
> still work with 16-bit code segments and 32-bit code segments.... but system
> descriptors use the 64-bit form (even while you're in compatibility mode...
> the only exception to this... in compatibility mode, the LDT descriptor is a
> 32-bit LDT).......   you go into 64-bit mode when you load CS with a
> selector of a descriptor that has bit 21 (now called the L bit... previously
> unused?) set to 1.... (and bit 22, the D bit...must be set to 0.... L=1, D=1
> is reserved for future use)....
> 
> anyways... yes i can see it still being possible to run v86 mode on a 64-bit
> OS.... but that'll be a very klunky hack..... you can forget about
> pre-emptive multitasking w/ mixed v86 and 64-bit.... this is because you
> have to disable paging before swapping between long mode and legacy
> mode,.... then re-enable paging, if desired.....   with that much work, you
> might as well put 64-bit applications on hold (along w/ any related 32-bit
> code segments or 16-bit code segments that go with that 64-bit app) while
> you work w/ v86 / pm16 / pm32...  then when the user doesn't need a v86
> session any longer.... ask the user if he/she is planning in using another
> v86 session, or if it would be okay for you to go back into long mode and
> allow 64-bit programs to continue running again....
> 
> anyways... i can see it possible to support both v86 mode and 64-bit
> mode.... but..... it's a real-time exclusive support.... you're either
> allowing v86 threads to run, or 64-bit threads to run... but both can't have
> a non-zero timeslice value at any one point in time, due to major overhead
> involved in swapping between the two....

You may look up the discussions in the x86-64 mailing list. The AMD 
engineers there stated explicitly that while "ugly hacks" like the above 
may work on current silicon, mode transitions as described are neither 
documented as valid nor are they architected and tested. So there is no 
guarantee that such magic will work on future silicon at all.

Ciao,
    Dani

0
Daniela
1/25/2004 5:05:35 PM
> I know that there's a similar situation with Win9x, where KERNEL, USER and
> GDI are still 16-bit, and thunks are used to interface 32-bit apps with

No, KERNEL32 is all 32bit, up to int21h calls to VMM. These bastards grab
global mutexes though around these calls :-(

> 16-bit user-mode code. Although Win9x's problems are said to stem from this
> mix of 16-bit code

No, mainly due to critical system tables opened for everyone's access, and due
to WIn16Lock and Krn32Lock. Neither of these have connection to 16bitness.

-- 
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com


0
Maxim
1/25/2004 8:32:49 PM
[Followup-To set to comp.arch.]

Don Eitner <freiheit@syntheticdimension-nospam.net> writes:

> No, because before you can gain the benefits of 64-bit computing,
> you need to drop the 16-bit code.  A pure 32-bit OS could be better
> than a hybrid 32/64-bit if it's done right, but a 16/32/64-bit OS
> would just be impossible to maintain for very long

I thought IBM's mainframe backwards compatibility stuff still
supported things like 31 bit architectures. Supposedly mainframes
made now could still run software written in the '60 and '70s.

Is this true?

Before the 8/16/32/64 bits became "mainstream" many architectures
used many different word lengths for addressing. (The word "octet" is
used to explicitly state that a byte/word is 8 bits, yes?)

-- 
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well 
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
0
David
1/25/2004 10:08:45 PM
David Magda wrote:
> [Followup-To set to comp.arch.]
> 
> Don Eitner <freiheit@syntheticdimension-nospam.net> writes:
> 
> 
>>No, because before you can gain the benefits of 64-bit computing,
>>you need to drop the 16-bit code.  A pure 32-bit OS could be better
>>than a hybrid 32/64-bit if it's done right, but a 16/32/64-bit OS
>>would just be impossible to maintain for very long
> 
> 
> I thought IBM's mainframe backwards compatibility stuff still
> supported things like 31 bit architectures. Supposedly mainframes
> made now could still run software written in the '60 and '70s.
> 
> Is this true?
> 
> Before the 8/16/32/64 bits became "mainstream" many architectures
> used many different word lengths for addressing. (The word "octet" is
> used to explicitly state that a byte/word is 8 bits, yes?)
> 

For instance, I (and many others) spent an important part of my
career using machines that sported 60 bit words (and others with
48 bit words).

0
CJT
1/25/2004 10:40:04 PM
"David Magda" <dmagda+trace031024@ee.ryerson.ca> wrote in message
news:86n08b4r6a.fsf@number6.magda.ca...
>
> I thought IBM's mainframe backwards compatibility stuff still
> supported things like 31 bit architectures. Supposedly mainframes
> made now could still run software written in the '60 and '70s.
>
> Is this true?

Well, I work in a place where where many of the programs were written in the
70's, and are still 24-bit (and run well enough on the newest systems) - so
I would say that is essentially true.    It probably wouldn't hurt
performance and resource usage if they were updated - but that becomes a
money issue.

Regards,
    Dean




0
Dean
1/25/2004 10:43:20 PM
"CJT" <abujlehc@prodigy.net> wrote in message
news:401445C4.2050206@prodigy.net...
> David Magda wrote:
> > [Followup-To set to comp.arch.]
> >
> > Don Eitner <freiheit@syntheticdimension-nospam.net> writes:
> >
> >
> >>No, because before you can gain the benefits of 64-bit computing,
> >>you need to drop the 16-bit code.  A pure 32-bit OS could be better
> >>than a hybrid 32/64-bit if it's done right, but a 16/32/64-bit OS
> >>would just be impossible to maintain for very long
> >
> >
> > I thought IBM's mainframe backwards compatibility stuff still
> > supported things like 31 bit architectures. Supposedly mainframes
> > made now could still run software written in the '60 and '70s.
> >
> > Is this true?
> >
> > Before the 8/16/32/64 bits became "mainstream" many architectures
> > used many different word lengths for addressing. (The word "octet" is
> > used to explicitly state that a byte/word is 8 bits, yes?)
> >
>
> For instance, I (and many others) spent an important part of my
> career using machines that sported 60 bit words (and others with
> 48 bit words).


To which I can add 18 / 24 / 28 / 30 bit systems.
None with an odd number of bits though :-)

-- 

   ...  Hank

Hank: http://horedson.home.att.net
W0RLI: http://w0rli.home.att.net


0
Hank
1/25/2004 11:36:12 PM
David Magda wrote:

> [Followup-To set to comp.arch.]

> Don Eitner <freiheit@syntheticdimension-nospam.net> writes:

>>No, because before you can gain the benefits of 64-bit computing,
>>you need to drop the 16-bit code.  A pure 32-bit OS could be better
>>than a hybrid 32/64-bit if it's done right, but a 16/32/64-bit OS
>>would just be impossible to maintain for very long

> I thought IBM's mainframe backwards compatibility stuff still
> supported things like 31 bit architectures. Supposedly mainframes
> made now could still run software written in the '60 and '70s.

> Is this true?

The current machines and OS support 64, 31, or 24 bit addressing
modes, including combinations of mixed modes.  The system keeps
track of which parts can address, and can be addressed by, each
mode.    For example, for a program running in 24 bit mode the
high bits of an address will be ignored.

Current OS and hardware will execute programs written and
compiled or assembled in the 1960s, including system
programs such as compilers and assemblers.

-- glen

0
glen
1/26/2004 1:37:21 AM
Here in comp.os.os2.misc,
David Magda <dmagda+trace031024@ee.ryerson.ca> spake unto us, saying:

>I thought IBM's mainframe backwards compatibility stuff still
>supported things like 31 bit architectures. Supposedly mainframes
>made now could still run software written in the '60 and '70s.
>
>Is this true?

I can't speak for IBM mainframes, but Unisys Clearpath IX mainframes
(which use a 36-bit word-addressable architecture derived from Sperry
1100-series machines) are still quite capable of running software
written in the 60's.

In fact, many (probably most) of the utility routines used heavily by
application code in the flight operations system that I worked on at
NWA were written in the mid- to late-60's.

The executable format changed at some point in the mid-70's, so they
actually had to be reassembled or recompiled, but it's still the same
software.

>Before the 8/16/32/64 bits became "mainstream" many architectures
>used many different word lengths for addressing. (The word "octet" is
>used to explicitly state that a byte/word is 8 bits, yes?)

The term "octet" indicates an 8-bit data element, yes.

Strangely enough, the Clearpath IX still stores ASCII data as 9-bit
bytes (quarter words) and FIELDATA characters in 6-bit bytes (sixth
words).

-- 
 -Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
  OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
     Applications analyst/designer/developer (14 yrs) seeking employment.
              See web site above for resume/CV and background.
0
rsteiner
1/26/2004 6:19:34 AM
David Magda <dmagda+trace031024@ee.ryerson.ca> wrote
> [Followup-To set to comp.arch.]
> Don Eitner <freiheit@syntheticdimension-nospam.net> writes:
> > No, because before you can gain the benefits of 64-bit computing,
> > you need to drop the 16-bit code.  A pure 32-bit OS could be better
> > than a hybrid 32/64-bit if it's done right, but a 16/32/64-bit OS
> > would just be impossible to maintain for very long
> I thought IBM's mainframe backwards compatibility stuff still
> supported things like 31 bit architectures. Supposedly mainframes
> made now could still run software written in the '60 and '70s.
> Is this true?
> Before the 8/16/32/64 bits became "mainstream" many architectures
> used many different word lengths for addressing. (The word "octet" is
> used to explicitly state that a byte/word is 8 bits, yes?)

 It is very easy to write portable code. All you have to do is to assume
 less about the basic data types. For example, store datas in byte arrays,
 and access them that way. Use the minimal requirements for each data type,
 for example the c type int is only guaranteed to be at least 16 bits, and
 that unsigned char arrays will be packed (and have the element size of an
 octet). Don't use bitfields and always read/write datas from byte arrays.

 By keeping all the rules, the resulting code will run on any system with
 a system word size from 8 bits to 64 or even more bits.

  Viktor

ps:
 How to read a 32 bit little endian unsigned integer from a file this way?
  unsigned char buf[4];  // 4 bytes
  unsigned long int v;   // the default int can be anything!

  fread(buf, 1, 4, f);
  v = buf[0] | (buf[1]<<8) | (buf[2]<<16) | (buf[3]<<24);
  // this code above is endian and system word size free
0
nospam777
1/26/2004 6:38:19 AM
In article <9f459d85.0401252238.1eb207aa@posting.google.com>,
 nospam777@freemail.hu (KVP) wrote:

> ps:
>  How to read a 32 bit little endian unsigned integer from a file this way?
>   unsigned char buf[4];  // 4 bytes
>   unsigned long int v;   // the default int can be anything!
> 
>   fread(buf, 1, 4, f);
>   v = buf[0] | (buf[1]<<8) | (buf[2]<<16) | (buf[3]<<24);
>   // this code above is endian and system word size free

Just add a few casts to unsigned long, because this code is broken if 
you have unsigned int < 32 bit.
0
Christian
1/26/2004 7:46:04 AM
Christian Bau <christian.bau@cbau.freeserve.co.uk> wrote
In article <9f459d85.0401252238.1eb207aa@posting.google.com>,
>  nospam777@freemail.hu (KVP) wrote:
> > ps:
> >  How to read a 32 bit little endian unsigned integer from a file this way?
> >   unsigned char buf[4];  // 4 bytes
> >   unsigned long int v;   // the default int can be anything!
> >   fread(buf, 1, 4, f);
> >   v = buf[0] | (buf[1]<<8) | (buf[2]<<16) | (buf[3]<<24);
> >   // this code above is endian and system word size free
> Just add a few casts to unsigned long, because this code is broken if 
> you have unsigned int < 32 bit.

 So, correctly:

 unsigned char buf[4];
 unsigned long int v;
 fread(buf, 1, 4, f);
 v = (((unsigned long int)buf[0])    )|
     (((unsigned long int)buf[1])<<8 )|
     (((unsigned long int)buf[2])<<16)|
     (((unsigned long int)buf[3])<<24);

 Btw: It's a bit tricky to write code that always works, but it's possible.
 The best solution is to wrap code like this into functions or macros.

  Viktor

ps:
 A configuration header can contain some platform specific defines for
 general data types. Afaik newer c standards already have such definitions
 like int64_t or uint64_t. They are guaranteed to be portable.
0
nospam777
1/26/2004 10:48:06 AM
KVP wrote:
> 
>  for example the c type int is only guaranteed to be at least 16 bits, and
> 
   Actually a C "int" defaults to the processor's natural integer size. 
So on a 16 bit processor an int is 16 bits; on a 32 bit processor it is 
32 bits. It was because of this ambiguity that "limits.h" came to be.


-- 
jimoe at sohnen-moe dot com
0
James
1/26/2004 5:46:59 PM
James Moe wrote:

> KVP wrote:
> 
>>
>>  for example the c type int is only guaranteed to be at least 16 bits, 
>> and
>>
>   Actually a C "int" defaults to the processor's natural integer size. 

To the *ABI's* natural integer size: there are many machines that have several
ABIs with different ILP size models...

-- 
Alexis Cousein                   Senior Systems Engineer
alexis@sgi.com                   SGI/Silicon Graphics Brussels
<opinions expressed here are my own, not those of my employer>
Nobody Expects the Belgian Inquisition!

0
Alexis
1/26/2004 6:00:58 PM
In <86n08b4r6a.fsf@number6.magda.ca>, on 01/25/2004
   at 05:08 PM, David Magda <dmagda+trace031024@ee.ryerson.ca> said:

>I thought IBM's mainframe backwards compatibility stuff still
>supported things like 31 bit architectures.

31? There's still code that runs with 24-bit addressing.

>Supposedly mainframes made now could still run software written in 
>the '60 and '70s.

Yes.

>Before the 8/16/32/64 bits became "mainstream" many architectures
>used many different word lengths for addressing. (The word "octet"
>is used to explicitly state that a byte/word is 8 bits, yes?)

Yes. 36, 48 and 60 bit word sizes were common, with 15 or 18 bit
addresses, and 12, 18, 24 and 30 bit word sizes were not unusual. Then
there were the oddballs like the UNIVAC III, and the decimal
computers. After the S/360 people, even at IBM, forgot what "byte"
meant and thought that it was synonymous with "octet". Prior to that,
people routinely referred to 6, 7 and 12 bit bytes.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do
not reply to spamtrap@library.lspace.org

0
Shmuel
1/26/2004 8:34:01 PM
I've been reading this article as well, but I've got to say that I 
missed one small part in this article. It forgets to mention that most 
software is written on 32-bit systems. It can be compiled as an 64-bit 
binary, but if the program internally uses int32 instead of an simple 
int it won't benefit much from the 64-bit architecture.

Besides; if it uses an int64 to store an int32 or has some protective 
code (MySQL could for example) like;
int check_max_value_int(int input)
{
	return ((input>=-32000) && (input<=3200))
}
It might even produce larger files when writing it into an binary form.

This test sounds like storing an boolean value into an integer to me.

Gr. Michael.

Alessandro Cantatore wrote:
> there is an interesting article with benchmarks regarding this subject:
> 
>  <http://www.osnews.com/story.php?news_id=5768>
> 
> BTW I think that lack of 64 bit is not a real problem for OS/2-eCS...
> (or not the main problem)
> 
> --
> bye
> Alessandro Cantatore
> email reply to: acantatore (at: tin.it)
0
Michael
1/26/2004 10:07:38 PM
Hank Oredson wrote:

> To which I can add 18 / 24 / 28 / 30 bit systems.
> None with an odd number of bits though :-)

Oh, but I started on a mainframe with 9 bit bytes :-)

[ Perhaps this doesn't count ... ]

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)

0
Toon
1/26/2004 11:06:25 PM
Bx.C wrote:
>>>>>>This brings up an interesting issue.  I know the Athlon 64 can run
> 
> 64-
> 
>>>>>>bit plus 32-bit in "compatibility mode" but does it also support
>>>>>>16-bit at the same time, or would it have to be done with emulation?
>>>>>
>>>>>In "long mode" there is no processor support for legacy operation
>>>>>modes (real, 16-bit protected and virtual x86). An emulation is
>>
>>required.
>>
>>>>In Long Mode, the x86-64 CPU runs 16-bit code in a 16-bit
> 
> compatibility
> 
>>>>sub-mode without recompilation.
>>>>
>>>> From the AMD docs (AMD64 Architecture Programmer's Manual Volume 1:
>>>>Application Programming Publication No. 24592 Revision Date 3.09
>>>>September 2003):
>>>>
>>>>"In compatibility mode, legacy 16-bit and 32-bit applications run
>>>>  using legacy x86 protected-mode segmentation semantics. The
>>>>  16-bit or 32-bit effective addresses generated by programs are
>>>>  combined with their segments to produce 32-bit virtual (linear)
>>>>  addresses that are zero-extended to a maximum of 64 bits.
>>>
>>>This makes things even worse.  Now, not only will 64-bit programs not
>>>have their registers saved and restored properly, but even 32-bit
>>>programs will clobber the portions of the registers that are not saved!
>>>
>>>
>>>>Note that both the 'compatibility' mode and the '64-bit' modes
> 
> referred
> 
>>to
>>
>>>>there are sub-modes of Long Mode.
>>>
>>>And can you execute 64-bit instructions in "compatibility" mode?  How
>>>about executing 16-bit instructions in "64-bit" mode?  It doesn't matter
>>>if they share a common parent mode if the two features that we want to
>>>interoperate are mutually exclusive.
>>>
>>
>>no.. you can only execute 64-bit instructions in a 64-bit code segment....
>>when you load CS with a selector for a 64-bit code segment, you are then
> 
> in
> 
>>64-bit mode... no longer in compatibility...
>>
>>though... i've been having to go over a few things in their docs several
>>times... (i can't wait till i can actually purchase an x86-64 system to
> 
> test
> 
>>this stuff)..... while the docs say that 16- and 32- bit programs can be
>>executed in compatibility mode (submode of long mode), another place in
> 
> the
> 
>>docs show that information as untrue.... (give me a few hours.. i'll
> 
> compile
> 
>>the info)...
>>
> 
> 
> 
> well it's been about 10 hours since I've posted this and my own newsserver
> hasn't shown it yet... so i'm posting it again..... sorry if this is a
> repost for ya'll....
> 
> 
> ok... here we go...
> 
> in Long Mode.... compatibility mode supports 16-bit protected mode code
> segments and 32-bit protected mode code segments.... no v86 under long
> mode.... also, there's two more important bits of info to know for Long
> mode.... all interrupts are to go to 64-bit code segments.....  and there's
> no hardware task swapping... you have a single 64-bit TSS.... (one good
> thing to know... we do have the option for separate stack pointers for each
> interrupt... so we can still handle stack-based problems via the doublefault
> handler)....
> 
> now... the reason i'd assume there's no hardware task swapping, is because
> we all know that software-based task swapping is faster anyway....  dunno
> why that is, considering the hardware in the CPU has access direct access to
> its own registers... it should be able to do it faster than a list of
> software instructions..... but for some reason, they haven't been able to do
> so...... but anyways....
> 
> Long mode is a very terrible creature when it tries dealing with its older
> sister, legacy mode....basically, you have to disable paging in legacy mode
> (CR0.PG=0)... set the long mode enable bit (LME) in the
> extended-feature-enable register (EFER... MSR# C000_0080h).... re-enable
> paging (CR0.PG=1)... (of course, paging under long mode isn't exactly the
> same).... as soon as you re-enable paging.... the processor will set the
> long mode activated flag (EFER.LMA)...  now, with EFER.LMA=1.... you can
> still work with 16-bit code segments and 32-bit code segments.... but system
> descriptors use the 64-bit form (even while you're in compatibility mode...
> the only exception to this... in compatibility mode, the LDT descriptor is a
> 32-bit LDT).......   you go into 64-bit mode when you load CS with a
> selector of a descriptor that has bit 21 (now called the L bit... previously
> unused?) set to 1.... (and bit 22, the D bit...must be set to 0.... L=1, D=1
> is reserved for future use)....
> 
> anyways... yes i can see it still being possible to run v86 mode on a 64-bit
> OS.... but that'll be a very klunky hack..... you can forget about
> pre-emptive multitasking w/ mixed v86 and 64-bit.... this is because you
> have to disable paging before swapping between long mode and legacy
> mode,.... then re-enable paging, if desired.....   with that much work, you
> might as well put 64-bit applications on hold (along w/ any related 32-bit
> code segments or 16-bit code segments that go with that 64-bit app) while
> you work w/ v86 / pm16 / pm32...  then when the user doesn't need a v86
> session any longer.... ask the user if he/she is planning in using another
> v86 session, or if it would be okay for you to go back into long mode and
> allow 64-bit programs to continue running again....

I don't see why you would want to switch to switch back to legacy mode 
from long mode in this case since the 16-bit and 32-bit software should 
still run in the compatibility sub-mode of long mode.  The 16-bit, 
32-bit, and 64-bit code segments should all be able to run in long mode, 
in either compatibility mode or 64-bit mode, providing that there is a 
new 64-bit OS/2 kernel, which would be needed to enable the long mode in 
the first place, and which would make the old virtual real mode unnecessary.

Going at it from a different direction, though, it seems like it might 
be possible to run some sort of 64-bit 'plug-in' from an already-booted 
32-bit OS/2 by the use of a 64-bit 'extender' that would load with long 
mode at boot and would then switch the cpu back to legacy mode to 
continue the normal OS/2 boot.  Then, to enable access to the larger 
long-mode memory space, the 64-bit extender could be activated which 
would switch the processor to long mode to support the plug-in function, 
whatever it might be.  When that finishes, the system would switch back 
to legacy mode, as you are describing above.  The 32-bit operation of 
the system would be suspended, of course, while the plugin was active, 
although I suppose that some 32-bit code could also be used by the 
plugin depending on how complex it was.  A 'plug-in' approach could 
practically only be used for relatively simple things since doing more 
than that would require much more complexity that would perhaps negate 
the point of using the approach in the first place.

> 
> anyways... i can see it possible to support both v86 mode and 64-bit
> mode.... but..... it's a real-time exclusive support.... you're either
> allowing v86 threads to run, or 64-bit threads to run... but both can't have
> a non-zero timeslice value at any one point in time, due to major overhead
> involved in swapping between the two....
> 
> 
> 
> 
> 
> 
> 


-- 
Posted with OS/2 Warp 4.52
and IBM Web Browser v2.0.2

0
David
1/27/2004 12:20:07 AM
In comp.arch James Moe <jimoeNOSPAM@sohnen-moe.com> wrote:
> KVP wrote:
> > 
> >  for example the c type int is only guaranteed to be at least 16 bits, and
> > 
>    Actually a C "int" defaults to the processor's natural integer size. 
> So on a 16 bit processor an int is 16 bits; on a 32 bit processor it is 
> 32 bits. It was because of this ambiguity that "limits.h" came to be.
> 

"Defaults to" is not even in the same galaxy as "is guaranteed to be". The
two might aswell be made one from antimatter and the other from regular and
there would be no fear of annihilation whatsoever. Assuming unwarranteed 
stuff about int is very bad. There is way more than neccessary amounts of very
unportable code.

-- 
	Sander

+++ Out of cheese error +++
0
Sander
1/27/2004 2:11:03 AM
Shmuel (Seymour J.) Metz infrared:

>Yes. 36, 48 and 60 bit word sizes were common, with 15 or 18 bit
>addresses, and 12, 18, 24 and 30 bit word sizes were not unusual. Then
>there were the oddballs like the UNIVAC III, and the decimal
>computers. After the S/360 people, even at IBM, forgot what "byte"
>meant and thought that it was synonymous with "octet". Prior to that,
>people routinely referred to 6, 7 and 12 bit bytes.

Don't forget punched paper tape with its 5-bit bytes.  8-column tape
didn't appear until later.

I think it was the PDP-10 that let the byte size be defined by
software.  In a single 36-bit word you could fit six 6-bit bytes
(the obvious choice for character manipulation); or five 7-bit
bytes (for dealing with that new-fangled ASCII); or probably a
few other combinations.

-- 
Peter Moylan                            Peter.Moylan@newcastle.edu.au
http://eepjm.newcastle.edu.au (OS/2 and eCS information and software)
0
peter
1/27/2004 2:26:38 AM

Shmuel (Seymour J.) Metz wrote:
> Yes. 36, 48 and 60 bit word sizes were common, with 15 or 18 bit
> addresses, and 12, 18, 24 and 30 bit word sizes were not unusual.

What were the 30 bit machines? The only one I remember was built by Adage (I 
worked there 30 years ago).  Every 15 bit combination in the high half of the 
word was (theoretically) a legal instruction.  Strange beast.


-- 

-------------------------------------------------------------------------
=    Jeff Kenton      Consulting and software development               =
=                     http://home.comcast.net/~jeffrey.kenton           =
-------------------------------------------------------------------------

0
Jeff
1/27/2004 3:13:17 AM
Sir:

David T. Johnson wrote:
> Going at it from a different direction, though, it seems like it might 
> be possible to run some sort of 64-bit 'plug-in' from an already-booted 
> 32-bit OS/2 by the use of a 64-bit 'extender' that would load with long 
> mode at boot and would then switch the cpu back to legacy mode to 
> continue the normal OS/2 boot.  Then, to enable access to the larger 
> long-mode memory space, the 64-bit extender could be activated which 
> would switch the processor to long mode to support the plug-in function, 
> whatever it might be.  When that finishes, the system would switch back 
> to legacy mode, as you are describing above.  The 32-bit operation of 
> the system would be suspended, of course, while the plugin was active, 
> although I suppose that some 32-bit code could also be used by the 
> plugin depending on how complex it was.  A 'plug-in' approach could 
> practically only be used for relatively simple things since doing more 
> than that would require much more complexity that would perhaps negate 
> the point of using the approach in the first place.

Care to write a deskview extender for 64-bits for OS/2.  Since the 
market is not there and Microsoft has a 64-bit operating system ready to 
ship as soon as Intel ships a compatible 64-bit chip, I don't think 
you'll get funding just for OS/2 market share as it already is possible 
to boot on the hardware as you've done.
-- 
Bill
Thanks a Million!

0
William
1/27/2004 5:27:16 AM
William L. Hartzell wrote:
> Sir:
> 
> David T. Johnson wrote:
> 
>> Going at it from a different direction, though, it seems like it might 
>> be possible to run some sort of 64-bit 'plug-in' from an 
>> already-booted 32-bit OS/2 by the use of a 64-bit 'extender' that 
>> would load with long mode at boot and would then switch the cpu back 
>> to legacy mode to continue the normal OS/2 boot.  Then, to enable 
>> access to the larger long-mode memory space, the 64-bit extender could 
>> be activated which would switch the processor to long mode to support 
>> the plug-in function, whatever it might be.  When that finishes, the 
>> system would switch back to legacy mode, as you are describing above.  
>> The 32-bit operation of the system would be suspended, of course, 
>> while the plugin was active, although I suppose that some 32-bit code 
>> could also be used by the plugin depending on how complex it was.  A 
>> 'plug-in' approach could practically only be used for relatively 
>> simple things since doing more than that would require much more 
>> complexity that would perhaps negate the point of using the approach 
>> in the first place.
> 
> 
> Care to write a deskview extender for 64-bits for OS/2.

I was thinking that a portion of the code in the AMD64 version of 
FreeBSD could be used for this, with some tweaking of course.

>  Since the 
> market is not there

The 64-bit market is an unknown at this point, in my view.

> and Microsoft has a 64-bit operating system ready to 
> ship as soon as Intel ships a compatible 64-bit chip,

I presume that you are not referring to the Itanium (which already has a 
64-bit Windows version shipping with it) but rather to the new 
'Prescott' chip which has been speculated to have some 64-bit 
capaabilities.  As it stands now, the Prescott chip is going to ship in 
just a few weeks and does not have any 64-bit capabilities but instead 
appears to be a just a Pentium 4 with even more pipeline stages to allow 
even higher clock rates.  Samples have already been delivered to media 
representatives under NDA and the 64-bit feature seems to be missing in 
action.  If Microsoft is waiting for Intel, there is not likely to be a 
new 64-bit version of Windows for a long time to come.  There is quite a 
bit of non-Windows 64-bit software beginning to appear for the AMD64 
hardware, though, including some powerful development tools.


> I don't think 
> you'll get funding just for OS/2 market share as it already is possible 
> to boot on the hardware as you've done.

My hand is not extended for funding.  :)




-- 
Posted with OS/2 Warp 4.52
and IBM Web Browser v2.0.2 

0
David
1/27/2004 4:10:03 PM
On Mon, 26 Jan 2004 15:34:01 -0500, "Shmuel (Seymour J.) Metz"
<spamtrap@library.lspace.org.invalid> wrote:

>In <86n08b4r6a.fsf@number6.magda.ca>, on 01/25/2004
>   at 05:08 PM, David Magda <dmagda+trace031024@ee.ryerson.ca> said:

>>Before the 8/16/32/64 bits became "mainstream" many architectures
>>used many different word lengths for addressing. (The word "octet"
>>is used to explicitly state that a byte/word is 8 bits, yes?)
>
>Yes. 36, 48 and 60 bit word sizes were common, with 15 or 18 bit
>addresses, and 12, 18, 24 and 30 bit word sizes were not unusual. Then
>there were the oddballs like the UNIVAC III, and the decimal
>computers. After the S/360 people, even at IBM, forgot what "byte"
>meant and thought that it was synonymous with "octet". Prior to that,
>people routinely referred to 6, 7 and 12 bit bytes.

Back when I started computing ( mid 60's he said showing his age ),
bytes were an IBM term for a group of 8 bits.  Other vendors used the
term character.  So there were x number of 5 bit, 6 bit, 7 bit, 8 bit,
and 9 bit characters to a word.  5 bit was baudot.  6 bit was used by
CDC (they had systems with 24 and 60 bit words) and was called
fielddata, if I remember correctly.  7 bit was ASCII. 8 bit was EBCDIC
(BCD was a 4 bit numeric code).  9 was used on 36 bit machines like the
PDP-10.

Octet was a term coined by European standards committees because they
didn't want to use IBM terminology.
0
Robert
1/27/2004 4:27:01 PM
On Tue, 27 Jan 2004 16:27:01 UTC, Robert Klute 
<robert_klute_removethis@hp.com> wrote:

> Back when I started computing ( mid 60's he said showing his age ),
> bytes were an IBM term for a group of 8 bits.  Other vendors used the
> term character.  So there were x number of 5 bit, 6 bit, 7 bit, 8 bit,
> and 9 bit characters to a word.  5 bit was baudot.  6 bit was used by
> CDC

And the PDP-8..

> (they had systems with 24 and 60 bit words) and was called
> fielddata, if I remember correctly.  7 bit was ASCII. 8 bit was EBCDIC
> (BCD was a 4 bit numeric code).  9 was used on 36 bit machines like the
> PDP-10.

Not really. The PDP-10 stored characters 5 to a word in virtually all 
cases, using the spare bit as a 'line number flag'. I don't think I ever
came across anything that used 9 bit for a byte - there would have been 
nothing to use the ninth bit for!


0
Bob
1/27/2004 5:36:20 PM
On Tue, 27 Jan 2004 17:36:20 UTC in comp.os.os2.programmer.misc, "Bob 
Eager" <rde42@spamcop.net> wrote:

> I don't think I ever
> came across anything that used 9 bit for a byte - there would have been 
> nothing to use the ninth bit for!

Unless you count parity...

-- 
Trevor Hemsley, Brighton, UK.
Trevor-Hemsley@dial.pipex.com
0
Trevor
1/27/2004 5:48:06 PM
On Tue, 27 Jan 2004 17:48:06 UTC, "Trevor Hemsley" 
<Trevor-Hemsley@no.spam.dial.pipex.com> wrote:

> On Tue, 27 Jan 2004 17:36:20 UTC in comp.os.os2.programmer.misc, "Bob 
> Eager" <rde42@spamcop.net> wrote:
> 
> > I don't think I ever
> > came across anything that used 9 bit for a byte - there would have been 
> > nothing to use the ninth bit for!
> 
> Unless you count parity...

It was a 7 bit basic ASCII, and the 8th bit was parity!

0
Bob
1/27/2004 6:14:10 PM
On 27 Jan 2004 17:36:20 GMT, "Bob Eager" <rde42@spamcop.net> wrote:

>On Tue, 27 Jan 2004 16:27:01 UTC, Robert Klute 
><robert_klute_removethis@hp.com> wrote:
>
>> Back when I started computing ( mid 60's he said showing his age ),
>> bytes were an IBM term for a group of 8 bits.  Other vendors used the
>> term character.  So there were x number of 5 bit, 6 bit, 7 bit, 8 bit,
>> and 9 bit characters to a word.  5 bit was baudot.  6 bit was used by
>> CDC
>
>And the PDP-8..
>
>> (they had systems with 24 and 60 bit words) and was called
>> fielddata, if I remember correctly.  7 bit was ASCII. 8 bit was EBCDIC
>> (BCD was a 4 bit numeric code).  9 was used on 36 bit machines like the
>> PDP-10.
>
>Not really. The PDP-10 stored characters 5 to a word in virtually all 
>cases, using the spare bit as a 'line number flag'. I don't think I ever
>came across anything that used 9 bit for a byte - there would have been 
>nothing to use the ninth bit for!

Yes, mostly it was ASCII on the PDP-10, but for some reason I seem to
remember there being 9 bit characters too.

0
Robert
1/27/2004 6:27:02 PM

Jeff Kenton wrote:
> 
> Shmuel (Seymour J.) Metz wrote:
> > Yes. 36, 48 and 60 bit word sizes were common, with 15 or 18 bit
> > addresses, and 12, 18, 24 and 30 bit word sizes were not unusual.
> 
> What were the 30 bit machines? The only one I remember was built by Adage (I
> worked there 30 years ago).  Every 15 bit combination in the high half of the
> word was (theoretically) a legal instruction.  Strange beast.
> 

Univac 490 & 494 were 30 bit, as I recall

Univac 418 (called a 1218 onboard ships) were 18 bit.

I saw a program card foir a UNIVAC 1050 cross my desk
last year (I dont know what is was doing here, we never
had that machine) and I thought it was 24 bits...

Hav a lookse at thr IBM 360/44...

-Willy
0
William
1/27/2004 11:20:53 PM
The GE / Honeywell / Bull 36 bit mainframes pack nine bit bytes into a 36
bit word.

 > I don't think I ever
> came across anything that used 9 bit for a byte - there would have been
> nothing to use the ninth bit for!


0
Bill
1/28/2004 1:10:57 AM
>The GE / Honeywell / Bull 36 bit mainframes pack nine bit bytes into a 36
>bit word.

Four 9-bit bytes or six 6-bit characters.

> > I don't think I ever
>> came across anything that used 9 bit for a byte - there would have been
>> nothing to use the ninth bit for!

Didn't Bill Gates once remark 
	"No one will ever need more than 8-bit bytes"


-- 
	mac the na�f
0
Alex
1/28/2004 3:16:09 AM
"Toon Moene" <toon@moene.indiv.nluug.nl> wrote in message
news:40159d4e$0$245$4d4ebb8e@news.nl.uu.net...
> Hank Oredson wrote:
>
> > To which I can add 18 / 24 / 28 / 30 bit systems.
> > None with an odd number of bits though :-)
>
> Oh, but I started on a mainframe with 9 bit bytes :-)
>
> [ Perhaps this doesn't count ... ]


Ah ... 6 chars in 36 bits, later 4 chars in 36 bits :-)

-- 

   ...  Hank

Hank: http://horedson.home.att.net
W0RLI: http://w0rli.home.att.net


0
Hank
1/28/2004 3:38:58 AM
"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
message news:401579b9$2$fuzhry+tra$mr2ice@news.patriot.net...
> In <86n08b4r6a.fsf@number6.magda.ca>, on 01/25/2004
>    at 05:08 PM, David Magda <dmagda+trace031024@ee.ryerson.ca> said:
>
> >I thought IBM's mainframe backwards compatibility stuff still
> >supported things like 31 bit architectures.
>
> 31? There's still code that runs with 24-bit addressing.
>
> >Supposedly mainframes made now could still run software written in
> >the '60 and '70s.
>
> Yes.
>
> >Before the 8/16/32/64 bits became "mainstream" many architectures
> >used many different word lengths for addressing. (The word "octet"
> >is used to explicitly state that a byte/word is 8 bits, yes?)
>
> Yes. 36, 48 and 60 bit word sizes were common, with 15 or 18 bit
> addresses, and 12, 18, 24 and 30 bit word sizes were not unusual. Then
> there were the oddballs like the UNIVAC III, and the decimal
> computers. After the S/360 people, even at IBM, forgot what "byte"
> meant and thought that it was synonymous with "octet". Prior to that,
> people routinely referred to 6, 7 and 12 bit bytes.
>
> -- 
>      Shmuel (Seymour J.) Metz, SysProg and JOAT
>
> Unsolicited bulk E-mail will be subject to legal action.  I reserve
> the right to publicly post or ridicule any abusive E-mail.
>
> Reply to domain Patriot dot net user shmuel+news to contact me.  Do
> not reply to spamtrap@library.lspace.org


Not to forget 9 bit bytes (4 per 36 bit word) as noted elsewhere in the thread.
"Gee, it's really 8 bits plus parity isn't it?"

Communications channels were worse. Dealt with one that
had 10 bit characters, with the upper three bits giving shift state
for the (one of) 127 keys on the keyboard that had been pressed.

-- 

   ...  Hank

Hank: http://horedson.home.att.net
W0RLI: http://w0rli.home.att.net


0
Hank
1/28/2004 3:43:59 AM
"William Robison" <william-robison@uiowa.edu> wrote in message
news:4016F255.84D8D733@uiowa.edu...
>
>
> Jeff Kenton wrote:
> >
> > Shmuel (Seymour J.) Metz wrote:
> > > Yes. 36, 48 and 60 bit word sizes were common, with 15 or 18 bit
> > > addresses, and 12, 18, 24 and 30 bit word sizes were not unusual.
> >
> > What were the 30 bit machines? The only one I remember was built by Adage
(I
> > worked there 30 years ago).  Every 15 bit combination in the high half of
the
> > word was (theoretically) a legal instruction.  Strange beast.
> >
>
> Univac 490 & 494 were 30 bit, as I recall
>
> Univac 418 (called a 1218 onboard ships) were 18 bit.
>
> I saw a program card foir a UNIVAC 1050 cross my desk
> last year (I dont know what is was doing here, we never
> had that machine) and I thought it was 24 bits...
>
> Hav a lookse at thr IBM 360/44...


Univac CP-667 had two modes as I recall, 36 and 30 bits (?)
In 36 bit mode it looked an awful lot like an 1107 / 1108.
Will have to ask my wife, she did a lot of programming on that machine.

-- 

   ...  Hank

Hank: http://horedson.home.att.net
W0RLI: http://w0rli.home.att.net


0
Hank
1/28/2004 3:45:51 AM
Sir:

David T. Johnson wrote:
> William L. Hartzell wrote:
> 
>> Sir:
>>
>> David T. Johnson wrote:
>>
>>> Going at it from a different direction, though, it seems like it 
>>> might be possible to run some sort of 64-bit 'plug-in' from an 
>>> already-booted 32-bit OS/2 by the use of a 64-bit 'extender' that 
>>> would load with long mode at boot and would then switch the cpu back 
>>> to legacy mode to continue the normal OS/2 boot.  Then, to enable 
>>> access to the larger long-mode memory space, the 64-bit extender 
>>> could be activated which would switch the processor to long mode to 
>>> support the plug-in function, whatever it might be.  When that 
>>> finishes, the system would switch back to legacy mode, as you are 
>>> describing above.  The 32-bit operation of the system would be 
>>> suspended, of course, while the plugin was active, although I suppose 
>>> that some 32-bit code could also be used by the plugin depending on 
>>> how complex it was.  A 'plug-in' approach could practically only be 
>>> used for relatively simple things since doing more than that would 
>>> require much more complexity that would perhaps negate the point of 
>>> using the approach in the first place.
>>
>>
>>
>> Care to write a deskview extender for 64-bits for OS/2.
> 
> 
> I was thinking that a portion of the code in the AMD64 version of 
> FreeBSD could be used for this, with some tweaking of course.
> 
>>  Since the market is not there
> 
> 
> The 64-bit market is an unknown at this point, in my view.
> 
>> and Microsoft has a 64-bit operating system ready to ship as soon as 
>> Intel ships a compatible 64-bit chip,
> 
> 
> I presume that you are not referring to the Itanium (which already has a 
> 64-bit Windows version shipping with it) but rather to the new 
> 'Prescott' chip which has been speculated to have some 64-bit 
> capaabilities.  As it stands now, the Prescott chip is going to ship in 
> just a few weeks and does not have any 64-bit capabilities but instead 
> appears to be a just a Pentium 4 with even more pipeline stages to allow 
> even higher clock rates.  Samples have already been delivered to media 
> representatives under NDA and the 64-bit feature seems to be missing in 
> action.  If Microsoft is waiting for Intel, there is not likely to be a 
> new 64-bit version of Windows for a long time to come.  There is quite a 
> bit of non-Windows 64-bit software beginning to appear for the AMD64 
> hardware, though, including some powerful development tools.

There is a 64-bit CPU in Intel's Labs (not Itanium, not Prescott). 
Microsoft told Intel that they must ship a chip with compatible 64-bit 
instructions with the AMD chip or not find Microsoft support for their 
64-bit line.  Intel is maddly working on such a chip and it is expected 
to ship sometime in the third quarter of this year.   Microsoft said 
they would withhold Windows XP64 until then (August).   The above is 
rumors, leaks, etc. I've found on MicroInquirer and other sites.  It 
does not help that HP (co-designer) is abandoning Itanium in favor of 
AMD's 64-bit server chip.

-- 
Bill
Thanks a Million!

0
William
1/28/2004 4:27:10 AM
In <slrnc1bj30.199.peter@eepjm.newcastle.edu.au>, on 01/27/2004
   at 02:26 AM, peter@seagoon.newcastle.edu.au (Peter Moylan) said:

>Don't forget punched paper tape with its 5-bit bytes.

The term byte hadn't been coined when Baudot was around. The word
originated with Project Stretch in the 1950s.

>I think it was the PDP-10 that let the byte size be defined by
>software.  

The IBM 7030 was there first, and even at DEC the PDP-6[1] was there
first.

>or probably a few other combinations.

It could be anything from 1 to 36 bits, but I assume that for
character chomping the vast majority of use was with 6 and 7 bits.

[1] I don't know how many were shipped before the 10 came out.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do
not reply to spamtrap@library.lspace.org

0
Shmuel
1/28/2004 4:40:44 AM
In <me3d10ljp2ajuooqbofv5upsp25g6fpfnu@4ax.com>, on 01/27/2004
   at 04:27 PM, Robert Klute <robert_klute_removethis@hp.com> said:

>Back when I started computing ( mid 60's he said showing his age ),
>bytes were an IBM term for a group of 8 bits.

No. A byte was defined as a string of bits, of whatever size. The
S/360 introduced the "Model T" use of "any color you want as long as
it's 8".

>Other vendors used the term character.

Sometimes. And sometimes not. Look at, e.g., the instruction set for
the DEC PDP-6 and PDP-10.

>6 bit was used by CDC (they had systems with 24 and 60 bit words)

And 12 and 48 and 64-bit words. Looking at page 1-1 in my trusty rusty
3600 manual, I see "Transmission of 48-bit words (12-bit bytes)"

>and was called fielddata, if I remember correctly. 

There were many 6-bit codes used by CDC. There were multiple codes
even on the same machine.

>(BCD was a 4 bit numeric code)

The term "BCD" was also used for a[1] six-bit code.

>Octet was a term coined by European standards committees because
>they didn't want to use IBM terminology.

No, because they didn't want to misuse it. An octet is a byte, but so
is half an octet.

[1] FSVO "a" greater than one.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do
not reply to spamtrap@library.lspace.org

0
Shmuel
1/28/2004 5:04:30 AM
Jeff Kenton  <Jeffrey.Kenton@comcast.net> wrote:
+---------------
| Shmuel (Seymour J.) Metz wrote:
| > Yes. 36, 48 and 60 bit word sizes were common, with 15 or 18 bit
| > addresses, and 12, 18, 24 and 30 bit word sizes were not unusual.
| 
| What were the 30 bit machines? The only one I remember was built by Adage...
+---------------

The Royal Precision/Librascope LGP-30 was another. Drum machine, with
vacuum tubes for non-drum CPU state (only 15 bits total!) and semiconductor
diode logic. [The entire "this-state/next-state" equation for the machine
was printed in a few pages of the maintenance manual!]


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607

0
rpw3
1/28/2004 12:42:45 PM
Jeff Kenton <Jeffrey.Kenton@comcast.net> wrote in
news:hHkRb.124462$5V2.649043@attbi_s53: 

> 
> 
> Shmuel (Seymour J.) Metz wrote:
>> Yes. 36, 48 and 60 bit word sizes were common, with 15 or 18 bit
>> addresses, and 12, 18, 24 and 30 bit word sizes were not unusual.
> 
> What were the 30 bit machines? The only one I remember was built by
> Adage (I worked there 30 years ago).  Every 15 bit combination in the
> high half of the word was (theoretically) a legal instruction. 
> Strange beast. 

I started out on a 39-bit machine. Each of the 8K words 
contained two 18-bit instructions. Semiconductor, bit serial
0.576ms instruction cycle time (2kips), magnetic film storage 
complete with sprocket holes, 5 channel paper tape. And a 
decent Algol-60 compiler fitted in 4Wwords.

0
Tom
1/28/2004 2:42:15 PM
"Bob Eager" <rde42@spamcop.net> writes:

> Not really. The PDP-10 stored characters 5 to a word in virtually all 
> cases, using the spare bit as a 'line number flag'. I don't think I ever
> came across anything that used 9 bit for a byte - there would have been 
> nothing to use the ninth bit for!

Stanford Extended ASCII.

-- 
Paul Repacholi                               1 Crescent Rd.,
+61 (08) 9257-1001                           Kalamunda.
                                             West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
0
Paul
1/28/2004 2:57:59 PM
On Wed, 28 Jan 2004 00:04:30 -0500, "Shmuel (Seymour J.) Metz"
<spamtrap@library.lspace.org.invalid> wrote:

>In <me3d10ljp2ajuooqbofv5upsp25g6fpfnu@4ax.com>, on 01/27/2004
>   at 04:27 PM, Robert Klute <robert_klute_removethis@hp.com> said:
>
>>Back when I started computing ( mid 60's he said showing his age ),
>>bytes were an IBM term for a group of 8 bits.
>
>No. A byte was defined as a string of bits, of whatever size. The
>S/360 introduced the "Model T" use of "any color you want as long as
>it's 8".

What little reference material I have left from the 60's, that is not
packed away, is from IBM.  For some reason I have always associated the
term byte with IBM.

I did check my old Knuth and by the mid-70's (probably before then, but
that is when my editions were published) he was defining byte as the
bits/digits required to represent a character.  For MIX it was 6 bits or
2 decimal digits.  


>>Other vendors used the term character.
>
>Sometimes. And sometimes not. Look at, e.g., the instruction set for
>the DEC PDP-6 and PDP-10.

That stuff is packed away, unfortunately.  I may still have material on
the PDP-5, PDP-8, PDP10, PDP-11, and PDP-12; but, it will be months
before I can get to it.

>>6 bit was used by CDC (they had systems with 24 and 60 bit words)
>
>And 12 and 48 and 64-bit words. Looking at page 1-1 in my trusty rusty
>3600 manual, I see "Transmission of 48-bit words (12-bit bytes)"

I worked on the 3000 series, 24 bit, and the 6000 series, 60 bit.


>>(BCD was a 4 bit numeric code)
>
>The term "BCD" was also used for a[1] six-bit code.

Wasn't that termed BCDIC? Or am I remembering wrong?

0
Robert
1/28/2004 4:26:00 PM
Robert Klute wrote:
> 
> Back when I started computing ( mid 60's he said showing his age ),
> bytes were an IBM term for a group of 8 bits.  Other vendors used the
> term character.  So there were x number of 5 bit, 6 bit, 7 bit, 8 bit,
> and 9 bit characters to a word.  5 bit was baudot.  6 bit was used by
> CDC (they had systems with 24 and 60 bit words) and was called
> fielddata, if I remember correctly.  7 bit was ASCII. 8 bit was EBCDIC
> (BCD was a 4 bit numeric code).  9 was used on 36 bit machines like the
> PDP-10.
> 
> Octet was a term coined by European standards committees because they
> didn't want to use IBM terminology.
I first learned assembler on the PDP-10. Although 9 bits divided the 36 
bit word evenly, the byte instructions were able to use any size byte. 
And for ASCII data, it used 7 bit bytes as standard in the software I 
saw, including the TOPS-10 operating system code.

0
Marc
1/28/2004 4:55:05 PM
> does not help that HP (co-designer) is abandoning Itanium in favor of
> AMD's 64-bit server chip.

IIRC Itanium in native mode is by far faster then AMD64, and there is native NT
for Itanium (and also Linux and HP-UX).

-- 
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com


0
Maxim
1/28/2004 5:39:49 PM
William L. Hartzell wrote:
> Sir:
> 
> David T. Johnson wrote:
> 
>> William L. Hartzell wrote:
>>
>>> Sir:
>>>
>>> David T. Johnson wrote:
>>>
>>>> Going at it from a different direction, though, it seems like it 
>>>> might be possible to run some sort of 64-bit 'plug-in' from an 
>>>> already-booted 32-bit OS/2 by the use of a 64-bit 'extender' that 
>>>> would load with long mode at boot and would then switch the cpu back 
>>>> to legacy mode to continue the normal OS/2 boot.  Then, to enable 
>>>> access to the larger long-mode memory space, the 64-bit extender 
>>>> could be activated which would switch the processor to long mode to 
>>>> support the plug-in function, whatever it might be.  When that 
>>>> finishes, the system would switch back to legacy mode, as you are 
>>>> describing above.  The 32-bit operation of the system would be 
>>>> suspended, of course, while the plugin was active, although I 
>>>> suppose that some 32-bit code could also be used by the plugin 
>>>> depending on how complex it was.  A 'plug-in' approach could 
>>>> practically only be used for relatively simple things since doing 
>>>> more than that would require much more complexity that would perhaps 
>>>> negate the point of using the approach in the first place.
>>>
>>>
>>>
>>>
>>> Care to write a deskview extender for 64-bits for OS/2.
>>
>>
>>
>> I was thinking that a portion of the code in the AMD64 version of 
>> FreeBSD could be used for this, with some tweaking of course.
>>
>>>  Since the market is not there
>>
>>
>>
>> The 64-bit market is an unknown at this point, in my view.
>>
>>> and Microsoft has a 64-bit operating system ready to ship as soon as 
>>> Intel ships a compatible 64-bit chip,
>>
>>
>>
>> I presume that you are not referring to the Itanium (which already has 
>> a 64-bit Windows version shipping with it) but rather to the new 
>> 'Prescott' chip which has been speculated to have some 64-bit 
>> capaabilities.  As it stands now, the Prescott chip is going to ship 
>> in just a few weeks and does not have any 64-bit capabilities but 
>> instead appears to be a just a Pentium 4 with even more pipeline 
>> stages to allow even higher clock rates.  Samples have already been 
>> delivered to media representatives under NDA and the 64-bit feature 
>> seems to be missing in action.  If Microsoft is waiting for Intel, 
>> there is not likely to be a new 64-bit version of Windows for a long 
>> time to come.  There is quite a bit of non-Windows 64-bit software 
>> beginning to appear for the AMD64 hardware, though, including some 
>> powerful development tools.
> 
> 
> There is a 64-bit CPU in Intel's Labs (not Itanium, not Prescott). 
> Microsoft told Intel that they must ship a chip with compatible 64-bit 
> instructions with the AMD chip or not find Microsoft support for their 
> 64-bit line.  Intel is maddly working on such a chip and it is expected 
> to ship sometime in the third quarter of this year.   Microsoft said 
> they would withhold Windows XP64 until then (August).   The above is 
> rumors, leaks, etc. I've found on MicroInquirer and other sites.  It 
> does not help that HP (co-designer) is abandoning Itanium in favor of 
> AMD's 64-bit server chip.
> 

I doubt very strongly that Intel will have anything resembling an AMD64 
chip to sell by 3rd quarter 2004.  3rd quarter 2006 I might believe. 
AMD has done a lot of water-carrying to get to where they are now with 
their Opteron and Athlon 64 chips and it takes time to do that.  For 
example, AMD has successfully gone to a Silicon-on-Insulator (SOI) 
process with the AMD64 chips while Intel has not which means that Intel 
is bumping up against heat dissipation limits with their current 
technology.  The latest Pentium 4 'Prescott' has been rumored to use 
more than 100 watts of power which is a *lot* of energy to release into 
a very small piece of silicon.  The AMD chips use much less power than 
that, thanks to SOI.  Also, the AMD design has a number of other 
features (such as the triple-pipeline FPU) that all benefit their move 
to the 64-bit design because they allow more operations to be done by 
the CPU at a slower clock speed.  The Pentium 4 has only been able to 
keep up with the AMD chips by increasing the clock speed and using 
special compiler software optimizations to produce flattering benchmarks.

AMD is set to start reaping the benefits of all of the hard work they 
have done for the last four years.  Intel needs to roll up their sleeves 
and get to work on their x86 hardware design if they want to keep up 
with AMD.  I think Intel was basically intending to abandon x86 and move 
to the Itanium but that now does not look like it will happen and so 
Intel is going to have to beef up their x86 silicon designs if they want 
to continue to support that hardware base.

-- 
Posted with OS/2 Warp 4.52
and IBM Web Browser v2.0.2

0
David
1/28/2004 6:08:08 PM
Here in comp.os.os2.misc,
Robert Klute <robert_klute_removethis@hp.com> spake unto us, saying:

>Back when I started computing ( mid 60's he said showing his age ),
>bytes were an IBM term for a group of 8 bits.  Other vendors used the
>term character.  So there were x number of 5 bit, 6 bit, 7 bit, 8 bit,
>and 9 bit characters to a word.  5 bit was baudot.  6 bit was used by
>CDC (they had systems with 24 and 60 bit words) and was called
>fielddata, if I remember correctly.

Yes, FIELDATA is a 6-bit code (it was also used on UNIVAC 1100-series
boxes and Unisys 2200-series boxes, which were 36-bit word-addressable
machines).

It's actually still in use at some places -- the series of flight ops
applications that I worked with until 2001 at NWA (WorldFlight) stored
most of its data as FIELDATA, and the current Unisys ClearPath IX line
of servers continues to use it (as well as 9-bit bytes for ASCII).

More info on FIELDATA can be found here:

  http://www.fourmilab.ch/documents/univac/fieldata.html

-- 
 -Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
  OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
     Applications analyst/designer/developer (14 yrs) seeking employment.
              See web site above for resume/CV and background.
0
rsteiner
1/28/2004 6:10:13 PM
On Wed, 28 Jan 2004 20:39:49 +0300, Maxim S. Shatskih wrote:

:>> does not help that HP (co-designer) is abandoning Itanium in favor of
:>> AMD's 64-bit server chip.
:>
:>IIRC Itanium in native mode is by far faster then AMD64, and there is native NT
:>for Itanium (and also Linux and HP-UX).

On Itanium performance, this article says something quite different: 

http://www.theregister.co.uk/content/61/35154.html

Mat Nieuwenhoven


0
Mat
1/28/2004 7:00:54 PM
On Wed, 28 Jan 2004 17:39:49 UTC, "Maxim S. Shatskih" 
<maxim@storagecraft.com> wrote:

> > does not help that HP (co-designer) is abandoning Itanium in favor of
> > AMD's 64-bit server chip.
> 
> IIRC Itanium in native mode is by far faster then AMD64, and there is native NT
> for Itanium (and also Linux and HP-UX).

And VMS.

0
Bob
1/28/2004 7:09:16 PM
In article <401742de$4$fuzhry+tra$mr2ice@news.patriot.net>,
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>
>There were many 6-bit codes used by CDC. There were multiple codes
>even on the same machine.

The ICL 1900 was similar.  It had disk code, card code and paper tape
code, which last supported lower case by the means of an interestingly
bizarre shift system.


Regards,
Nick Maclaren.
0
nmm1
1/28/2004 7:12:55 PM
Mind you, how can you represent 2 decimal digits with 6 bits? There are only
64 combinations for six bits...

-- 

ifconfig
BAGOS
http://bagos.sourceforge.net


"Robert Klute" <news@klute.us> wrote in message
news:tfnf105q148eseelr2rb6cvmgdbbgq0cis@4ax.com...
> On Wed, 28 Jan 2004 00:04:30 -0500, "Shmuel (Seymour J.) Metz"
> <spamtrap@library.lspace.org.invalid> wrote:
>
>  <SNIP>
> I did check my old Knuth and by the mid-70's (probably before then, but
> that is when my editions were published) he was defining byte as the
> bits/digits required to represent a character.  For MIX it was 6 bits or
> 2 decimal digits.
> <SNAP>


0
ifconfig
1/28/2004 8:18:45 PM
Paul Repacholi wrote:

> "Bob Eager" <rde42@spamcop.net> writes:
> 
> 
>>Not really. The PDP-10 stored characters 5 to a word in virtually all 
>>cases, using the spare bit as a 'line number flag'. I don't think I ever
>>came across anything that used 9 bit for a byte - there would have been 
>>nothing to use the ninth bit for!
> 
> Stanford Extended ASCII.

'Control-Meta-Cocebottle'?

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
0
Terje
1/28/2004 8:56:00 PM
Sir:

Maxim S. Shatskih wrote:
>>does not help that HP (co-designer) is abandoning Itanium in favor of
>>AMD's 64-bit server chip.
> 
> 
> IIRC Itanium in native mode is by far faster then AMD64, and there is native NT
> for Itanium (and also Linux and HP-UX).
> 
How many years has the Itanium been shipping?  AMD has sold more 
Opterons than Intel has Itanium in the past three months.  Remember that 
the Athlon64 is competing against the Pentium 4 chip family, not the 
server class chips, so don't go mixing apples and oranges.  There is 
nothing called AMD64.
-- 
Bill
Thanks a Million!

0
William
1/28/2004 8:57:13 PM
On Wed, 28 Jan 2004 22:18:45 +0200, "ifconfig" <dor@ntr.co.il> wrote:

>Mind you, how can you represent 2 decimal digits with 6 bits? There are only
>64 combinations for six bits...

The MIX computer was both decimal and binary.  So it was either 2
decimal digit (00-99) or 6 bits (0-63).
0
Robert
1/28/2004 9:33:25 PM
How exactly does it keep the 2 decimal digits?

-- 

ifconfig
BAGOS
http://bagos.sourceforge.net


"Robert Klute" <robert_klute_removethis@hp.com> wrote in message
news:3cag10tuvqanahltt1rb7rvgi55vov9spp@4ax.com...
> On Wed, 28 Jan 2004 22:18:45 +0200, "ifconfig" <dor@ntr.co.il> wrote:
>
> >Mind you, how can you represent 2 decimal digits with 6 bits? There are
only
> >64 combinations for six bits...
>
> The MIX computer was both decimal and binary.  So it was either 2
> decimal digit (00-99) or 6 bits (0-63).


0
ifconfig
1/28/2004 9:41:42 PM
Nick Maclaren wrote:
> The ICL 1900 was similar.  It had disk code, card code and paper tape
> code, which last supported lower case by the means of an interestingly
> bizarre shift system.

More complicated than Baudot's SI/SO codes, tehn?

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
0
Terje
1/28/2004 9:51:52 PM
On Wed, 28 Jan 2004 23:41:42 +0200, "ifconfig" <dor@ntr.co.il> wrote:

>How exactly does it keep the 2 decimal digits?

It was a teaching simulation that only really existed in his 'Art of
Computer Programming' Opus.  It couild anything the Donald Knuth wanted
it to do.  So, it was both a binary and a decimal computer. 


Here is the Wikipedia reference for it:
http://en2.wikipedia.org/wiki/MIX

-----------------
Richard M. Stallman, Linus Torvalds, and Donald E. Knuth engage in a
discussion on whose impact on the computerized world was the greatest.

Stallman: "God told me I have programmed the best editor in the world!"

Torvalds: "Well, God told *me* that I have programmed the best operating
system in the world!"

Knuth: "Wait, wait - I never said that."


0
Robert
1/28/2004 10:16:01 PM
In article <bv9atn$a9e$1@osl016lin.hda.hydro.com>,
Terje Mathisen  <terje.mathisen@hda.hydro.com> wrote:
>Nick Maclaren wrote:
>> The ICL 1900 was similar.  It had disk code, card code and paper tape
>> code, which last supported lower case by the means of an interestingly
>> bizarre shift system.
>
>More complicated than Baudot's SI/SO codes, tehn?

Yes.  It had alpha, beta and delta shifts.  The first two were like
SI/SO, and the last applied only to the next character (i.e. it was
an escape character).


Regards,
Nick Maclaren.
0
nmm1
1/28/2004 10:48:00 PM
nmm1@cus.cam.ac.uk (Nick Maclaren) wrote in 
news:bv9e70$dss$1@pegasus.csx.cam.ac.uk:

> In article <bv9atn$a9e$1@osl016lin.hda.hydro.com>,
> Terje Mathisen  <terje.mathisen@hda.hydro.com> wrote:
>>Nick Maclaren wrote:
>>> The ICL 1900 was similar.  It had disk code, card code and paper tape
>>> code, which last supported lower case by the means of an interestingly
>>> bizarre shift system.
>>
>>More complicated than Baudot's SI/SO codes, tehn?
> 
> Yes.  It had alpha, beta and delta shifts.  The first two were like
> SI/SO, and the last applied only to the next character (i.e. it was
> an escape character).

And I thought the Ferranti and Elliott 5-channel paper 
tape's "letter-shift" and "figure-shift" were bad!

I dimly recall something even worse; so bad that I
didn't bother to use it. ICL 2900 Algol in which the
keywords had to be escaped by a "'" character, and 
the "'"s themselves had to be escaped! Stunning.
I hope nobody can dredge up the details of that 
foul memory.
0
Tom
1/29/2004 12:04:48 AM
Captain's log. On StarDate Wed, 28 Jan 2004 10:08:08 -0800 received comm from
"David T. Johnson" <djohnson@isomedia.com> on channel comp.os.os2.misc:

: I doubt very strongly that Intel will have anything resembling an AMD64 
: chip to sell by 3rd quarter 2004.  3rd quarter 2006 I might believe. 
: AMD has done a lot of water-carrying to get to where they are now with 
: their Opteron and Athlon 64 chips and it takes time to do that.  For 

[ snip ]

: AMD is set to start reaping the benefits of all of the hard work they 
: have done for the last four years.  Intel needs to roll up their sleeves 
: and get to work on their x86 hardware design if they want to keep up 

I don't have any specific schedule for release, so I can't comment on the time
frame the previous poster had, but over two years ago I got some *very* reliable
insider information that Intel had a 64-bit x86 working in their labs, and at
that time (about two years ago) had in fact been working on such a product plan
for several years as a backup if Intel would fail with their Itanium line and
AMD succeed with their 64-bit x86 line.

: with AMD.  I think Intel was basically intending to abandon x86 and move 
: to the Itanium but that now does not look like it will happen and so 
: Intel is going to have to beef up their x86 silicon designs if they want 
: to continue to support that hardware base.

Even if Intel releases a 64-bit x86 line of processors, I think they still will
keep the IA-64 (Itanium, etc) architecture as their long term goal for the
market (if the market will accept that or not is another matter).

The Alpha processors was much better and faster than the x86 at the time, but
that didn't help them, so I'm not sure that only raw performance will save the
IA-64 if it hasn't a lot of optimized applications and broad hardware support.

I think the biggest hope for the future of Intel IA-64 is that processor
independent software based on technologies such as Java and .NET reaches a
broader scale than they have today.

Best regards,

martin t�rnsten

-- 
http://82.182.73.126/
0
Martin
1/29/2004 12:07:26 AM
On Thu, 29 Jan 2004 00:04:48 UTC, Tom Gardner <tggzzz@blueyonder.co.uk> 
wrote:

> I dimly recall something even worse; so bad that I
> didn't bother to use it. ICL 2900 Algol in which the
> keywords had to be escaped by a "'" character, and 
> the "'"s themselves had to be escaped! Stunning.
> I hope nobody can dredge up the details of that 
> foul memory.

I don't recall the details, and indeed that compiler was so bug rudden 
it was never ready for prime time.

We changed to the alternative Edinburgh ALGOL compiler, and *never* 
found a bug in it (there was a bottle of whisky for anyone who did).

Indeed, we also stopped using the ICL operating system, and I ended up 
doing low level work on the kernel of our replacement, as well as 
another compiler. An interesting architecture....32 bits but also 64 and
128....variable size accumulator. Come to that, I remember evolving a 
microcode patch to correct for a hardware design flaw!
0
Bob
1/29/2004 12:50:50 AM
On Wed, 28 Jan 2004 20:57:13 GMT, William L. Hartzell wrote:

>Sir:
>
>Maxim S. Shatskih wrote:
>>>does not help that HP (co-designer) is abandoning Itanium in favor of
>>>AMD's 64-bit server chip.
>> 
>> 
>> IIRC Itanium in native mode is by far faster then AMD64, and there is native NT
>> for Itanium (and also Linux and HP-UX).
>> 
>How many years has the Itanium been shipping?  AMD has sold more 
>Opterons than Intel has Itanium in the past three months.  Remember that 
>the Athlon64 is competing against the Pentium 4 chip family, not the 
>server class chips, so don't go mixing apples and oranges.  There is 
>nothing called AMD64.

AMD64 is the official name of the 64-bit architecture used by the Opteron
and Athlon64 chips.

And for the record, the only area where Itanium is faster than the Opteron
is in floating point.


--
 - Mike

Remove 'spambegone.net' and reverse to send e-mail.


0
Mike
1/29/2004 2:24:52 AM
Sir:

David T. Johnson wrote:

> I doubt very strongly that Intel will have anything resembling an AMD64 
> chip to sell by 3rd quarter 2004.  3rd quarter 2006 I might believe.
<http://story.news.yahoo.com/news?tmpl=story&cid=569&ncid=738&e=2&u=/nm/20040129/tc_nm/tech_intel_64bit_dc>
Talk about fortutious forcasting.
-- 
Bill
Thanks a Million!

0
William
1/29/2004 7:42:10 AM
"Bob Eager" <rde42@spamcop.net> wrote
> On Thu, 29 Jan 2004 00:04:48 UTC, Tom Gardner <tggzzz@blueyonder.co.uk> 
> wrote:
> > I dimly recall something even worse; so bad that I
> > didn't bother to use it. ICL 2900 Algol in which the
> > keywords had to be escaped by a "'" character, and 
> > the "'"s themselves had to be escaped! Stunning.
> > I hope nobody can dredge up the details of that 
> > foul memory.
> I don't recall the details, and indeed that compiler was so bug rudden 
> it was never ready for prime time.
> We changed to the alternative Edinburgh ALGOL compiler, and *never* 
> found a bug in it (there was a bottle of whisky for anyone who did).
> Indeed, we also stopped using the ICL operating system, and I ended up 
> doing low level work on the kernel of our replacement, as well as 
> another compiler. An interesting architecture....32 bits but also 64 and
> 128....variable size accumulator. Come to that, I remember evolving a 
> microcode patch to correct for a hardware design flaw!

 This structure can be found in today's x86 line too. It supports 8, 16, 32
 (and with amd64 64) bit wide registers. This is fairly common. Even an 8 bit
 computer can support wider register sets, all it needs is microcode or
 compiler support.

  Viktor
0
nospam777
1/29/2004 8:15:35 AM
"Bob Eager" <rde42@spamcop.net> wrote
> On Thu, 29 Jan 2004 00:04:48 UTC, Tom Gardner <tggzzz@blueyonder.co.uk> 
> wrote:
> > I dimly recall something even worse; so bad that I
> > didn't bother to use it. ICL 2900 Algol in which the
> > keywords had to be escaped by a "'" character, and 
> > the "'"s themselves had to be escaped! Stunning.
> > I hope nobody can dredge up the details of that 
> > foul memory.
> I don't recall the details, and indeed that compiler was so bug rudden 
> it was never ready for prime time.
> We changed to the alternative Edinburgh ALGOL compiler, and *never* 
> found a bug in it (there was a bottle of whisky for anyone who did).
> Indeed, we also stopped using the ICL operating system, and I ended up 
> doing low level work on the kernel of our replacement, as well as 
> another compiler. An interesting architecture....32 bits but also 64 and
> 128....variable size accumulator. Come to that, I remember evolving a 
> microcode patch to correct for a hardware design flaw!

 This structure can be found in today's x86 line too. It supports 8, 16, 32
 (and with amd64 64) bit wide registers. This is fairly common. Even an 8 bit
 computer can support wider register sets, all it needs is microcode or
 compiler support.

  Viktor
0
nospam777
1/29/2004 8:16:00 AM
Robert Klute  <robert_klute_removethis@hp.com> wrote:
+---------------
| "ifconfig" <dor@ntr.co.il> wrote:
| >Mind you, how can you represent 2 decimal digits with 6 bits?
| >There are only 64 combinations for six bits...
| 
| The MIX computer was both decimal and binary.  So it was either 2
| decimal digit (00-99) or 6 bits (0-63).
+---------------

Small correction: While it is true that Knuth did use the word "both"
in one place ["TAoCP" Section 1.3.1] when describing MIX, what he meant
was that a given concrete instance of MIX may be *either* decimal or
binary or *any* other basis you like [such as ternary], provided only that
the following condition is met: A byte shall hold at least 64 distinct
values (states, codepoints, whatever) but no more than 100 distinct values.
A binary machine with 6 bits per byte satisfies this, as does a decimal
machine with 2 digits per byte, or a ternary machine with 4 trits per
bytes, or some weird piece of alien hardware with 73 states per storage
element, whatever.

A given instance of MIX is not "both" (or if you consider ternary, "all
three") bases at once, only that the basis is unspecified by the MIX
architecture. The programmer cannot depend on there being more than 64
distinct values per byte *nor* depend on there being *only* 64 distinct
values per byte. There are at least 64, and no more than 100. Correct
MIX programs must function properly no matter how many values per byte
there are (between 64 & 100, inclusive), though IIRC the number may be
assumed to be constant during any single run of a program.


-Rob

p.s. Extra credit: Besides the first three bases mentioned above,
there are only three other integral base/power pairs that meet the MIX
criterion for a byte [that is, such that (<= 64 (expt base power) 100),
expressed in Lisp]. What are they? And why are they "uninteresting"?

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607

0
rpw3
1/29/2004 1:03:11 PM
William L. Hartzell wrote:
> Sir:
> 
> David T. Johnson wrote:
> 
>> I doubt very strongly that Intel will have anything resembling an 
>> AMD64 chip to sell by 3rd quarter 2004.  3rd quarter 2006 I might 
>> believe.
> 
> <http://story.news.yahoo.com/news?tmpl=story&cid=569&ncid=738&e=2&u=/nm/20040129/tc_nm/tech_intel_64bit_dc> 
> 
> Talk about fortutious forcasting.

I would agree with that.  This is the first time that Intel has 
'officially' said anything about a 64-bit x86 chip.  However, talking 
about it is still a long way from shipping a competitive product.  I'll 
stay with my 3rd quarter 2006 timeline for now.

-- 
Posted with OS/2 Warp 4.52
and IBM Web Browser v2.0.2

0
David
1/29/2004 4:00:59 PM
[A complimentary Cc of this posting was sent to
Rob Warnock
<rpw3@rpw3.org>], who wrote in article <LN-dnYlZz8wSmYTdXTWc-g@speakeasy.net>:
> p.s. Extra credit: Besides the first three bases mentioned above,
> there are only three other integral base/power pairs that meet the MIX
> criterion for a byte [that is, such that (<= 64 (expt base power) 100),
> expressed in Lisp]. What are they? And why are they "uninteresting"?

Extra extra credit: find 37 more bases. ;-)

Ilya
0
Ilya
1/29/2004 9:01:25 PM
Ilya Zakharevich wrote:

> [A complimentary Cc of this posting was sent to
> Rob Warnock
> <rpw3@rpw3.org>], who wrote in article <LN-dnYlZz8wSmYTdXTWc-g@speakeasy.net>:
> 
>>p.s. Extra credit: Besides the first three bases mentioned above,
>>there are only three other integral base/power pairs that meet the MIX
>>criterion for a byte [that is, such that (<= 64 (expt base power) 100),
>>expressed in Lisp]. What are they? And why are they "uninteresting"?
> 
> 
> Extra extra credit: find 37 more bases. ;-)

Those are the obvious ones.

4 and 8 would seem to work as well, but effectively only as a different 
way to view the binary machine.

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
0
Terje
1/29/2004 9:39:30 PM
On Thu, 29 Jan 2004 07:03:11 -0600, Rob Warnock <rpw3@rpw3.org> wrote:
> Robert Klute  <robert_klute_removethis@hp.com> wrote:
> +---------------
>| "ifconfig" <dor@ntr.co.il> wrote:
>| >Mind you, how can you represent 2 decimal digits with 6 bits?
>| >There are only 64 combinations for six bits...
>| 
>| The MIX computer was both decimal and binary.  So it was either 2
>| decimal digit (00-99) or 6 bits (0-63).
> +---------------
>
> Small correction: While it is true that Knuth did use the word "both"
> in one place ["TAoCP" Section 1.3.1] when describing MIX, what he meant
> was that a given concrete instance of MIX may be *either* decimal or
> binary or *any* other basis you like [such as ternary], provided only that
> the following condition is met: A byte shall hold at least 64 distinct
> values (states, codepoints, whatever) but no more than 100 distinct values.
> A binary machine with 6 bits per byte satisfies this, as does a decimal
> machine with 2 digits per byte, or a ternary machine with 4 trits per
> bytes, or some weird piece of alien hardware with 73 states per storage
> element, whatever.
>
> A given instance of MIX is not "both" (or if you consider ternary, "all
> three") bases at once, only that the basis is unspecified by the MIX
> architecture. The programmer cannot depend on there being more than 64
> distinct values per byte *nor* depend on there being *only* 64 distinct
> values per byte. There are at least 64, and no more than 100. Correct
> MIX programs must function properly no matter how many values per byte
> there are (between 64 & 100, inclusive), though IIRC the number may be
> assumed to be constant during any single run of a program.
>
>
> -Rob
>
> p.s. Extra credit: Besides the first three bases mentioned above,
> there are only three other integral base/power pairs that meet the MIX
> criterion for a byte [that is, such that (<= 64 (expt base power) 100),
> expressed in Lisp]. What are they? And why are they "uninteresting"?


I'll bite. The powers go from 6 to 1, and we have the bases from
2 to 100. We already have base (power 6), 3 (power 4) and 10 (power 2).
The power 1 is the easiest, any base from 64 to 100 would
meet the criterion.

Let's see if there are any others. For power 2
exp(ln(64)/2) = 8 and exp(ln(100)/2) = 10. So two base 8 or base 9
digits would be OK, as well as the base 10 already mentioned.

For power 3.
exp(ln(64)/3) = 4 and exp(ln(100)/3) = 4.4. So 3 base 4 digits would be
OK.

For power 4
exp(ln(64)/4) = 2.8 and exp(ln(100)/4) = 3.1. 3's the only integer in
that interval.

For power 5. The base needs to be between
exp(ln(64)/5) = 2.2 and exp(ln(100)/5) = 2.5. There's no integer in that
interval.

For power 6
exp(ln(64)/5) = 2 and exp(ln(100)/5) = 2.2. 2's the only integer in that
interval.

So the three others are 2 base 8 or 9 digits and 3 base 4 digits. (and
all of the 1 digit bases from 64 to 100 which you don't seem to be
counting). Why are they 'uninteresting'? I guess because none of them
are relatively prime to the other 3 (base 2, 3 and 10).

A bientot
Paul
-- 
Paul Floyd                 http://paulf.free.fr (for what it's worth)
Surgery: ennobled Gerald.
0
Paul
1/29/2004 10:08:56 PM
> I would agree with that.  This is the first time that Intel has 
> 'officially' said anything about a 64-bit x86 chip.  However, talking
> about it is still a long way from shipping a competitive product. 
> I'll stay with my 3rd quarter 2006 timeline for now.
> 

Indeed. Remember the Itanium was supposed to be released in 1998, got 
pushed back to 99, then 2000.  People blasted IBM for not having a 64-
bit OS/2 strategy ready for the Itanium in 1998.  Those same people are 
still running Windows on a 32-bit processor in 2004.

-- 
Don "Freiheit" Eitner
Hobby eComStation & OS/2 developer
http://freiheit.syntheticdimension.net
0
Don
1/29/2004 10:22:23 PM
I think that's what he meant - the other bases are 4, 8 and 9, and are
uninteresting because they are all powers of other bases.

-- 

ifconfig
BAGOS
http://bagos.sourceforge.net


"Terje Mathisen" <terje.mathisen@hda.hydro.com> wrote in message
news:bvbuik$op0$1@osl016lin.hda.hydro.com...
> Ilya Zakharevich wrote:
>
> > [A complimentary Cc of this posting was sent to
> > Rob Warnock
> > <rpw3@rpw3.org>], who wrote in article
<LN-dnYlZz8wSmYTdXTWc-g@speakeasy.net>:
> >
> >>p.s. Extra credit: Besides the first three bases mentioned above,
> >>there are only three other integral base/power pairs that meet the MIX
> >>criterion for a byte [that is, such that (<= 64 (expt base power) 100),
> >>expressed in Lisp]. What are they? And why are they "uninteresting"?
> >
> >
> > Extra extra credit: find 37 more bases. ;-)
>
> Those are the obvious ones.
>
> 4 and 8 would seem to work as well, but effectively only as a different
> way to view the binary machine.
>
> Terje
>
> -- 
> - <Terje.Mathisen@hda.hydro.com>
> "almost all programming can be viewed as an exercise in caching"


0
ifconfig
1/29/2004 10:23:27 PM
In comp.arch Paul Floyd <root@127.0.0.1> wrote:
> 
> I'll bite. The powers go from 6 to 1, and we have the bases from
> 2 to 100. We already have base (power 6), 3 (power 4) and 10 (power 2).
> The power 1 is the easiest, any base from 64 to 100 would
> meet the criterion.
> 
> Let's see if there are any others. For power 2
> exp(ln(64)/2) = 8 and exp(ln(100)/2) = 10. So two base 8 or base 9
> digits would be OK, as well as the base 10 already mentioned.
> 
> For power 3.
> exp(ln(64)/3) = 4 and exp(ln(100)/3) = 4.4. So 3 base 4 digits would be
> OK.
> 
> For power 4
> exp(ln(64)/4) = 2.8 and exp(ln(100)/4) = 3.1. 3's the only integer in
> that interval.
> 
> For power 5. The base needs to be between
> exp(ln(64)/5) = 2.2 and exp(ln(100)/5) = 2.5. There's no integer in that
> interval.
> 
> For power 6
> exp(ln(64)/5) = 2 and exp(ln(100)/5) = 2.2. 2's the only integer in that
> interval.
> 
> So the three others are 2 base 8 or 9 digits and 3 base 4 digits. (and
> all of the 1 digit bases from 64 to 100 which you don't seem to be
> counting). Why are they 'uninteresting'? I guess because none of them
> are relatively prime to the other 3 (base 2, 3 and 10).

Well, you omited base-9, 2 digits. This should in fact have been fairly
obvious from base 3, 4 digits.

> 
> A bientot
> Paul

-- 
	Sander

+++ Out of cheese error +++
0
Sander
1/30/2004 12:58:20 AM
Sir:

Don Eitner wrote:
>>I would agree with that.  This is the first time that Intel has 
>>'officially' said anything about a 64-bit x86 chip.  However, talking
>>about it is still a long way from shipping a competitive product. 
>>I'll stay with my 3rd quarter 2006 timeline for now.
>>
> 
> 
> Indeed. Remember the Itanium was supposed to be released in 1998, got 
> pushed back to 99, then 2000.  People blasted IBM for not having a 64-
> bit OS/2 strategy ready for the Itanium in 1998.  Those same people are 
> still running Windows on a 32-bit processor in 2004.
> 
Ever since AMD said that they were going to develop an 64-bit X86 
version of its product line, Intel has had a development team (in 
Oregon) working on its version.  Intel could have shipped it last fall, 
but that Microsoft insisted that it be compatible with the AMD chip.  So 
Intel has had to work on its microcode for compatibility reasons. 
Rumors has it being a hot chip also on the smaller die (Intel taken the 
delay to migrate it to the smaller die).  Believe that the fab doing the 
testing of it is in Taipei (but only because of some Chinese reports of 
some unusual "Prescott" chips, much different than the Singapore fab's 
"Prescott" chips).  If AMD shipped their chip already, Intel surely has 
had enough time to do so also.  Remember that Intel has about ten times 
the resources of AMD.  IMHO.
-- 
Bill
Thanks a Million!

0
William
1/30/2004 9:27:13 AM
> p.s. Extra credit: Besides the first three bases mentioned above,
> there are only three other integral base/power pairs that meet the MIX
> criterion for a byte [that is, such that (<= 64 (expt base power)
> 100), expressed in Lisp]. What are they? And why are they
> "uninteresting"?

My TAoCP isn't within reach at the moment .. are negative bases
allowed?

mfc


0
Mike
1/30/2004 2:04:13 PM
William L. Hartzell wrote:
> Sir:
> 
> Don Eitner wrote:
> 
>>> I would agree with that.  This is the first time that Intel has 
>>> 'officially' said anything about a 64-bit x86 chip.  However, talking
>>> about it is still a long way from shipping a competitive product. 
>>> I'll stay with my 3rd quarter 2006 timeline for now.
>>>
>>
>>
>> Indeed. Remember the Itanium was supposed to be released in 1998, got 
>> pushed back to 99, then 2000.  People blasted IBM for not having a 64-
>> bit OS/2 strategy ready for the Itanium in 1998.  Those same people 
>> are still running Windows on a 32-bit processor in 2004.
>>
> Ever since AMD said that they were going to develop an 64-bit X86 
> version of its product line, Intel has had a development team (in 
> Oregon) working on its version.  Intel could have shipped it last fall, 
> but that Microsoft insisted that it be compatible with the AMD chip.

I don't think that Intel could have shipped it then or now because the 
product is simply not ready.  It takes time to develop a competitive 
product.  AMD was sending out 800 Mhz samples of its 64-bit chips two 
years ago but it took them more than a year after that to get the bugs 
out and release the very first Opterons in April, 2003.

>  So 
> Intel has had to work on its microcode for compatibility reasons.

There is a *lot* of work that needs to be done *after* the basic design 
on the die has been finalized.  If Intel is still working on microcode, 
they are even further behind AMD than I might have thought.

> Rumors 
> has it being a hot chip also on the smaller die (Intel taken the delay 
> to migrate it to the smaller die).

Intel is trying to use their current process with a die shrink while AMD 
has taken the time to successfully implement the much-more-difficult 
Silicon-on-insulator (SOI) process that results in a chip that 
dissipates much less heat and therefore runs cooler.  It will take Intel 
at least two years of *hard* work to convert one of their FABs to SOI 
IMHO and I think it is inevitable that they will be forced by market 
realities to do that to remain competitive with AMD.

>  Believe that the fab doing the 
> testing of it is in Taipei (but only because of some Chinese reports of 
> some unusual "Prescott" chips, much different than the Singapore fab's 
> "Prescott" chips).  If AMD shipped their chip already, Intel surely has 
> had enough time to do so also.  Remember that Intel has about ten times 
> the resources of AMD.  IMHO.\


Intel has more resources but they have been using those resources to 
climb a long way up the wrong tree.


-- 
Posted with OS/2 Warp 4.52
and IBM Web Browser v2.0.2

0
David
1/30/2004 4:52:29 PM
Don Eitner wrote:
>>I would agree with that.  This is the first time that Intel has 
>>'officially' said anything about a 64-bit x86 chip.  However, talking
>>about it is still a long way from shipping a competitive product. 
>>I'll stay with my 3rd quarter 2006 timeline for now.
>>
> 
> 
> Indeed. Remember the Itanium was supposed to be released in 1998, got 
> pushed back to 99, then 2000.  People blasted IBM for not having a 64-
> bit OS/2 strategy ready for the Itanium in 1998.  Those same people are 
> still running Windows on a 32-bit processor in 2004.
> 
Yes, I can recall that very clearly.  It would have been a big waste of 
OS/2 developer resources to create an OS/2 version for the Itanium.  I 
think IBM would be very smart, though, to release a 64-bit kernel for 
OS/2 that runs on the x86-64 chips.

-- 
Posted with OS/2 Warp 4.52
and IBM Web Browser v2.0.2

0
David
1/30/2004 4:54:28 PM
Sir:

David T. Johnson wrote:
> William L. Hartzell wrote:
> 
>> Sir:
>>
>> Don Eitner wrote:
>>
>>>> I would agree with that.  This is the first time that Intel has 
>>>> 'officially' said anything about a 64-bit x86 chip.  However, talking
>>>> about it is still a long way from shipping a competitive product. 
>>>> I'll stay with my 3rd quarter 2006 timeline for now.
>>>>
>>>
>>>
>>> Indeed. Remember the Itanium was supposed to be released in 1998, got 
>>> pushed back to 99, then 2000.  People blasted IBM for not having a 64-
>>> bit OS/2 strategy ready for the Itanium in 1998.  Those same people 
>>> are still running Windows on a 32-bit processor in 2004.
>>>
>> Ever since AMD said that they were going to develop an 64-bit X86 
>> version of its product line, Intel has had a development team (in 
>> Oregon) working on its version.  Intel could have shipped it last 
>> fall, but that Microsoft insisted that it be compatible with the AMD 
>> chip.
> 
> 
> I don't think that Intel could have shipped it then or now because the 
> product is simply not ready.  It takes time to develop a competitive 
> product.  AMD was sending out 800 Mhz samples of its 64-bit chips two 
> years ago but it took them more than a year after that to get the bugs 
> out and release the very first Opterons in April, 2003.
> 
>>  So Intel has had to work on its microcode for compatibility reasons.
> 
> 
> There is a *lot* of work that needs to be done *after* the basic design 
> on the die has been finalized.  If Intel is still working on microcode, 
> they are even further behind AMD than I might have thought.
> 
>> Rumors has it being a hot chip also on the smaller die (Intel taken 
>> the delay to migrate it to the smaller die).
> 
> 
> Intel is trying to use their current process with a die shrink while AMD 
> has taken the time to successfully implement the much-more-difficult 
> Silicon-on-insulator (SOI) process that results in a chip that 
> dissipates much less heat and therefore runs cooler.  It will take Intel 
> at least two years of *hard* work to convert one of their FABs to SOI 
> IMHO and I think it is inevitable that they will be forced by market 
> realities to do that to remain competitive with AMD.
How about samples next month? <http://www.theinquirer.net/?article=13895>
BTW, SOI is an IBM technology.  IBM will require Intel to give up its 
most important patents in an sharing agreement to get access to SOI.
> 
>>  Believe that the fab doing the testing of it is in Taipei (but only 
>> because of some Chinese reports of some unusual "Prescott" chips, much 
>> different than the Singapore fab's "Prescott" chips).  If AMD shipped 
>> their chip already, Intel surely has had enough time to do so also.  
>> Remember that Intel has about ten times the resources of AMD.  IMHO.\
> 
> 
> 
> Intel has more resources but they have been using those resources to 
> climb a long way up the wrong tree.
> 
> 

-- 
Bill
Thanks a Million!

0
William
1/30/2004 5:12:16 PM
William L. Hartzell wrote:
> Sir:
> 
> David T. Johnson wrote:
> 
>> William L. Hartzell wrote:
>>
>>> Sir:
>>>
>>> Don Eitner wrote:
>>>
>>>>> I would agree with that.  This is the first time that Intel has 
>>>>> 'officially' said anything about a 64-bit x86 chip.  However, talking
>>>>> about it is still a long way from shipping a competitive product. 
>>>>> I'll stay with my 3rd quarter 2006 timeline for now.
>>>>>
>>>>
>>>>
>>>> Indeed. Remember the Itanium was supposed to be released in 1998, 
>>>> got pushed back to 99, then 2000.  People blasted IBM for not having 
>>>> a 64-
>>>> bit OS/2 strategy ready for the Itanium in 1998.  Those same people 
>>>> are still running Windows on a 32-bit processor in 2004.
>>>>
>>> Ever since AMD said that they were going to develop an 64-bit X86 
>>> version of its product line, Intel has had a development team (in 
>>> Oregon) working on its version.  Intel could have shipped it last 
>>> fall, but that Microsoft insisted that it be compatible with the AMD 
>>> chip.
>>
>>
>>
>> I don't think that Intel could have shipped it then or now because the 
>> product is simply not ready.  It takes time to develop a competitive 
>> product.  AMD was sending out 800 Mhz samples of its 64-bit chips two 
>> years ago but it took them more than a year after that to get the bugs 
>> out and release the very first Opterons in April, 2003.
>>
>>>  So Intel has had to work on its microcode for compatibility reasons.
>>
>>
>>
>> There is a *lot* of work that needs to be done *after* the basic 
>> design on the die has been finalized.  If Intel is still working on 
>> microcode, they are even further behind AMD than I might have thought.
>>
>>> Rumors has it being a hot chip also on the smaller die (Intel taken 
>>> the delay to migrate it to the smaller die).
>>
>>
>>
>> Intel is trying to use their current process with a die shrink while 
>> AMD has taken the time to successfully implement the 
>> much-more-difficult Silicon-on-insulator (SOI) process that results in 
>> a chip that dissipates much less heat and therefore runs cooler.  It 
>> will take Intel at least two years of *hard* work to convert one of 
>> their FABs to SOI IMHO and I think it is inevitable that they will be 
>> forced by market realities to do that to remain competitive with AMD.
> 
> How about samples next month? <http://www.theinquirer.net/?article=13895>

The article says "...show off its technology..." rather than 'show off 
working samples.'  However, even if they have working samples, which I 
doubt, they will not be produced using the SOI process, will not have 
hyperthreading, will not have an integrated memory controller, and might 
not even be compatible with x86-64 instructions.  I'll stay with my '3rd 
quarter 2006' timeline for now.  :)

> BTW, SOI is an IBM technology.  IBM will require Intel to give up its 
> most important patents in an sharing agreement to get access to SOI.

IBM prefers to trade technology rather than license it, which makes a 
lot of sense when you think about it.  Intel prefers not to either share 
or license their technology.  A rock is meeting an immovable 
force...which will win?  Stay tuned...

> 
>>
>>>  Believe that the fab doing the testing of it is in Taipei (but only 
>>> because of some Chinese reports of some unusual "Prescott" chips, 
>>> much different than the Singapore fab's "Prescott" chips).  If AMD 
>>> shipped their chip already, Intel surely has had enough time to do so 
>>> also.  Remember that Intel has about ten times the resources of AMD.  
>>> IMHO.\
>>
>>
>>
>>
>> Intel has more resources but they have been using those resources to 
>> climb a long way up the wrong tree.
>>
>>
> 


-- 
Posted with OS/2 Warp 4.52
and IBM Web Browser v2.0.2

0
David
1/30/2004 5:33:13 PM
Sir:

David T. Johnson wrote:
> William L. Hartzell wrote:
> 
>> Sir:
>>
>> David T. Johnson wrote:
<snip>
>>> Intel is trying to use their current process with a die shrink while 
>>> AMD has taken the time to successfully implement the 
>>> much-more-difficult Silicon-on-insulator (SOI) process that results 
>>> in a chip that dissipates much less heat and therefore runs cooler.  
>>> It will take Intel at least two years of *hard* work to convert one 
>>> of their FABs to SOI IMHO and I think it is inevitable that they will 
>>> be forced by market realities to do that to remain competitive with AMD.
>>
>>
>> How about samples next month? <http://www.theinquirer.net/?article=13895>
> 
> 
> The article says "...show off its technology..." rather than 'show off 
> working samples.'  However, even if they have working samples, which I 
> doubt, they will not be produced using the SOI process, will not have 
> hyperthreading, will not have an integrated memory controller, and might 
> not even be compatible with x86-64 instructions.  I'll stay with my '3rd 
> quarter 2006' timeline for now.  :)
> 

In that article is a link to another article, which is more along the 
speculation line, but is interesting.  That article is saying 4th 
quarter this year at the earliest, with this time next year as best 
guess.  I'll stick for the moment with my estimate that Intel will 
surprise us.
-- 
Bill
Thanks a Million!

0
William
1/30/2004 6:12:14 PM
Mike Cowlishaw wrote:

>>p.s. Extra credit: Besides the first three bases mentioned above,
>>there are only three other integral base/power pairs that meet the MIX
>>criterion for a byte [that is, such that (<= 64 (expt base power)
>>100), expressed in Lisp]. What are they? And why are they
>>"uninteresting"?

> My TAoCP isn't within reach at the moment .. are negative bases
> allowed?

Mine isn't, either.

How about imaginary bases?

-- glen

0
glen
1/30/2004 6:23:00 PM
On Tue, 27 Jan 2004 02:26:38 UTC, peter@seagoon.newcastle.edu.au 
(Peter Moylan) wrote:

> Shmuel (Seymour J.) Metz infrared:
> 
> >Yes. 36, 48 and 60 bit word sizes were common, with 15 or 18 bit
> >addresses, and 12, 18, 24 and 30 bit word sizes were not unusual. Then
> >there were the oddballs like the UNIVAC III, and the decimal
> >computers. After the S/360 people, even at IBM, forgot what "byte"
> >meant and thought that it was synonymous with "octet". Prior to that,
> >people routinely referred to 6, 7 and 12 bit bytes.
> 
> Don't forget punched paper tape with its 5-bit bytes.  8-column tape
> didn't appear until later.
> 
> I think it was the PDP-10 that let the byte size be defined by
> software.  In a single 36-bit word you could fit six 6-bit bytes
> (the obvious choice for character manipulation); or five 7-bit
> bytes (for dealing with that new-fangled ASCII); or probably a
> few other combinations.
> 
My very first job as developer was on a mashine which had a 12 digit 
word - not a single byte but 12 decimal digits. There was no 
possibility to address anything els than a single 12 digit word. The 
mashine was coded in decimal words. Anything that was not a decimal 
digit was interpreted as memory fault.


-- 
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation

0
The
1/31/2004 10:29:23 AM
Sir:

William L. Hartzell wrote:
> Sir:
> 
> David T. Johnson wrote:
<snip>
>> The article says "...show off its technology..." rather than 'show off 
>> working samples.'  However, even if they have working samples, which I 
>> doubt, they will not be produced using the SOI process, will not have 
>> hyperthreading, will not have an integrated memory controller, and 
>> might not even be compatible with x86-64 instructions.  I'll stay with 
>> my '3rd quarter 2006' timeline for now.  :)
Try this link <http://www.techweb.com/wire/story/TWB20040130S0006>
-- 
Bill
Thanks a Million!

0
William
1/31/2004 9:57:18 PM
On Wed, 28 Jan 2004 20:00:54 +0100 (CET), Mat Nieuwenhoven wrote:

:>On Wed, 28 Jan 2004 20:39:49 +0300, Maxim S. Shatskih wrote:
:>
:>:>> does not help that HP (co-designer) is abandoning Itanium in favor of
:>:>> AMD's 64-bit server chip.
:>:>
:>:>IIRC Itanium in native mode is by far faster then AMD64, and there is native NT
:>:>for Itanium (and also Linux and HP-UX).
:>
:>On Itanium performance, this article says something quite different: 
:>
:>http://www.theregister.co.uk/content/61/35154.html
:>
:>Mat Nieuwenhoven
:>
:>



0
Mat
2/1/2004 1:18:01 PM
On Wed, 28 Jan 2004 20:39:49 +0300, Maxim S. Shatskih wrote:

:>> does not help that HP (co-designer) is abandoning Itanium in favor of
:>> AMD's 64-bit server chip.
:>
:>IIRC Itanium in native mode is by far faster then AMD64, and there is native NT
:>for Itanium (and also Linux and HP-UX).

Yet another indication that Itanium isn't such a good chip: 

http://www.infoworld.com/infoworld/article/04/01/30/05FElinux_2.html

I think the basic Itanium architecture is wrong, if with the same (Intel)
process technology this new architecture results in slower overall
performance than the classic x86 architecture, like Xeon, let alone AMD64 
(this is not to say that x86 is the best ever architecture). I remember there
was white paper from Compaq or Dec that compared Alpha and Itanium
architectures, which explained why Itanium's wasn't good.

Mat Nieuwenhoven


0
Mat
2/1/2004 1:24:28 PM
In <tfnf105q148eseelr2rb6cvmgdbbgq0cis@4ax.com>, on 01/28/2004
   at 04:26 PM, Robert Klute <news@klute.us> said:

>What little reference material I have left from the 60's, that is not
>packed away, is from IBM.  For some reason I have always associated
>the term byte with IBM.

AFAIK the IBM 7030 (Stretch) was developed by IBM. The term "byte" was
coined in conjunction with Project Stretch.

>I worked on the 3000 series, 24 bit,

There were at least two distinct CDC series with 3xxx model numbers,
and neither the 3600 nor the 3800 had a 24-bit word; both were 48-bit
words. I assume that you worked on a 3300 or some such, but those were
*not* either the first or the largest CDC processors with a 3xxx model
number.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT

Unsolicited bulk E-mail will be subject to legal action.  I reserve
the right to publicly post or ridicule any abusive E-mail.

Reply to domain Patriot dot net user shmuel+news to contact me.  Do
not reply to spamtrap@library.lspace.org

0
Shmuel
2/1/2004 3:46:45 PM
On Sun, 01 Feb 2004 14:24:28 +0100 (CET), Mat Nieuwenhoven wrote:

:>On Wed, 28 Jan 2004 20:39:49 +0300, Maxim S. Shatskih wrote:
:>
:>:>> does not help that HP (co-designer) is abandoning Itanium in favor of
:>:>> AMD's 64-bit server chip.
:>:>
:>:>IIRC Itanium in native mode is by far faster then AMD64, and there is native NT
:>:>for Itanium (and also Linux and HP-UX).
:>
:>Yet another indication that Itanium isn't such a good chip: 
:>
:>http://www.infoworld.com/infoworld/article/04/01/30/05FElinux_2.html
:>
:>I think the basic Itanium architecture is wrong, if with the same (Intel)
:>process technology this new architecture results in slower overall
:>performance than the classic x86 architecture, like Xeon, let alone AMD64 
:>(this is not to say that x86 is the best ever architecture). I remember there
:>was white paper from Compaq or Dec that compared Alpha and Itanium
:>architectures, which explained why Itanium's wasn't good.

Found it again: http://www.raytheon-computers.com/ref_docs/alpha_ia64.pdf

Googling for alpha_ia64.pdf finds several more related documents

Mat Nieuwenhoven


0
Mat
2/1/2004 6:31:03 PM
On Fri, 30 Jan 2004 00:58:20 +0000 (UTC), Sander Vesik
   <sander@haldjas.folklore.ee> wrote:
> In comp.arch Paul Floyd <root@127.0.0.1> wrote:
>> 
>> Let's see if there are any others. For power 2
>> exp(ln(64)/2) = 8 and exp(ln(100)/2) = 10. So two base 8 or base 9
>> digits would be OK, as well as the base 10 already mentioned.
>
> Well, you omited base-9, 2 digits. This should in fact have been fairly
> obvious from base 3, 4 digits.

Well what do you think "So two base 8 or base 9 digits would be OK"
means?

A bientot
Paul
-- 
Paul Floyd                 http://paulf.free.fr (for what it's worth)
Surgery: ennobled Gerald.
0
Paul
2/2/2004 1:27:53 PM
Reply:

Web resources about - 64 vs. 32 bits - comp.os.os2.programmer.misc

Bits of Freedom - Wikipedia, the free encyclopedia
Bits Of Freedom is an independent Dutch digital rights foundation, which focus on privacy and communications freedom in the digital age. The ...

Technology - Bits Blog - NYTimes.com
The Bits blog from the New York Times reports on the technology industry, including start-ups, the Internet, enterprise and gadgets

NYT Bits Blog (@nytimesbits) on Twitter
Sign in Sign up You are on Twitter Mobile because you are using an old version of Internet Explorer. Learn more here NYT Bits Blog @ nytimesbits ...

BITS 2014 on the App Store on iTunes
Get BITS 2014 on the App Store. See screenshots and ratings, and read customer reviews.

Little Bits
jurvetson posted a photo: TED Fellow Ayah Bdeir introduces littleBits, a set of simple, interchangeable blocks that make programming a craft, ...

Interpreters and Compilers (Bits and Bytes, Episode 6) - YouTube
This animation explains the difference between interpreters and compilers. It is from Episode 6 of the classic 1983 television series, Bits and ...

Bits of black bear found in Chinese medicine
Some Chinese medicines contain potentially poisonous plants, unlabelled ingredients and bits of endangered animals, a study has found, prompting ...

Where Hollywood Sees Art, Silicon Valley Sees 'Bits & Bytes'; Who's Winning?
... in the past, AllThingsD&#39;s Kara Swisher tells TheWrap&#39;s Sharon Waxman at TheGrill Where Hollywood sees art, Silicon Valley sees bits, ...

Gen Z's Data Obsession: Bits and Bytes Are the New Commodity
... is not expensive, the real cost of entry into the mobile market can be attributed to data. In a hyper-connected mobile-everything world, bits ...

Mobile Game Roundup: Unkilled, Fishy Bits and More
Mobile Game Roundup: Unkilled, Fishy Bits and More

Resources last updated: 1/31/2016 4:23:25 PM