Some early benchmarks for P4EE

[Yousuf Khan]

http://www.theinquirer.net/?article=11670

Ace's Hardware seems to be seeing between 2-15% improvement from the 2MB L3
cache.

Ace's will also be doing a head to head against processors from a "rival"
processor manufacturer in a couple of days, when their NDA expires. Stay
tuned.

Yousuf Khan

[Judd]

"Yousuf Khan" <bbbl67.spam@yahoo.com.nospam> wrote in message
news:PV5bb.5762$Lnr1.5118@news01.bloor.is.net.cable.rogers.com... http://www.theinquirer.net/?article=11670 Ace's Hardware seems to be seeing between 2-15% improvement from the 2MB
L3 cache. Ace's will also be doing a head to head against processors from a "rival" processor manufacturer in a couple of days, when their NDA expires. Stay tuned.

Toms Hardware did a benchmark and the P4EE won on just about every benchmark
over the highest rated A64 (the FX or whatever it is). The P4 3.2 and the
A64 were about even on the tests though Toms hardware claimed the FX was
victorious (not sure how they came to that conclusion). It looks like Intel
has stemmed the tide for now and has time to release it's Prescott (no
reason to hurry).

[Bill Todd]

"Judd" <IhateSpam@stopspam.com> wrote in message
news:21Fcb.55$oD4.29834@news.uswest.net... "Yousuf Khan" <bbbl67.spam@yahoo.com.nospam> wrote in message news:PV5bb.5762$Lnr1.5118@news01.bloor.is.net.cable.rogers.com... http://www.theinquirer.net/?article=11670 Ace's Hardware seems to be seeing between 2-15% improvement from the 2MB L3 cache. Ace's will also be doing a head to head against processors from a
"rival" processor manufacturer in a couple of days, when their NDA expires. Stay tuned. Toms Hardware did a benchmark and the P4EE won on just about every
benchmark over the highest rated A64 (the FX or whatever it is).

Your rose-colored glasses need a new prescription: P4EE won only about 2/3
of the tests - and but for its clean sweep of the MPEG and MP3 encoding
tests would have won only about half of them.

- bill

[Judd]

"Bill Todd" <billtodd@metrocast.net> wrote in message
news:48acndKC9_4tsu6iU-KYgA@metrocast.net... "Judd" <IhateSpam@stopspam.com> wrote in message news:21Fcb.55$oD4.29834@news.uswest.net... "Yousuf Khan" <bbbl67.spam@yahoo.com.nospam> wrote in message news:PV5bb.5762$Lnr1.5118@news01.bloor.is.net.cable.rogers.com... http://www.theinquirer.net/?article=11670 Ace's Hardware seems to be seeing between 2-15% improvement from the
2MB L3 cache. Ace's will also be doing a head to head against processors from a "rival" processor manufacturer in a couple of days, when their NDA expires.
Stay tuned. Toms Hardware did a benchmark and the P4EE won on just about every benchmark over the highest rated A64 (the FX or whatever it is). Your rose-colored glasses need a new prescription: P4EE won only about
2/3 of the tests - and but for its clean sweep of the MPEG and MP3 encoding tests would have won only about half of them.

Back at it again as always, LOL. Every post I make about Intel is sure to
get a Bill Todd response crying for AMD. Truth is, Intel is competing
without Prescott and who would have thunk. Things will be interesting over
the next few months.

[Shuttie]

"Judd" <IhateSpam@stopspam.com> wrote in message
news:t6Icb.67$oD4.41687@news.uswest.net... "Bill Todd" <billtodd@metrocast.net> wrote in message news:48acndKC9_4tsu6iU-KYgA@metrocast.net... "Judd" <IhateSpam@stopspam.com> wrote in message news:21Fcb.55$oD4.29834@news.uswest.net... "Yousuf Khan" <bbbl67.spam@yahoo.com.nospam> wrote in message news:PV5bb.5762$Lnr1.5118@news01.bloor.is.net.cable.rogers.com... > http://www.theinquirer.net/?article=11670 > > Ace's Hardware seems to be seeing between 2-15% improvement from the 2MB L3 > cache. > > Ace's will also be doing a head to head against processors from a "rival" > processor manufacturer in a couple of days, when their NDA expires. Stay > tuned. > Toms Hardware did a benchmark and the P4EE won on just about every benchmark over the highest rated A64 (the FX or whatever it is). Your rose-colored glasses need a new prescription: P4EE won only about 2/3 of the tests - and but for its clean sweep of the MPEG and MP3 encoding tests would have won only about half of them. Back at it again as always, LOL. Every post I make about Intel is sure to get a Bill Todd response crying for AMD. Truth is, Intel is competing without Prescott and who would have thunk. Things will be interesting
over the next few months.
I join with Jud in LOL. "P4EE won only about 2/3"

A "mod" on an old PCU kicking a brand new (well a discussion on its own) 1.

[Carlo Razzeto]

"Judd" <IhateSpam@stopspam.com> wrote in message
news:21Fcb.55$oD4.29834@news.uswest.net... Toms Hardware did a benchmark and the P4EE won on just about every
benchmark over the highest rated A64 (the FX or whatever it is). The P4 3.2 and the A64 were about even on the tests though Toms hardware claimed the FX was victorious (not sure how they came to that conclusion). It looks like
Intel has stemmed the tide for now and has time to release it's Prescott (no reason to hurry).

You know what the great thing about benchmarks are? You can prove anything
you want to prove! For every Tom's Hardware type site that found that the
P4EE was the clear winner, there was another site such and Anandtech.com
that found AMD64 to be the winner. In the end I think the situation remains
the same... People should be buying the best processor for the job they want
it to do. And for get about stupid allegiances to particular platforms.

Carlo

[Bill Todd]

"Judd" <IhateSpam@stopspam.com> wrote in message
news:t6Icb.67$oD4.41687@news.uswest.net...

....
Back at it again as always, LOL. Every post I make about Intel is sure to get a Bill Todd response crying for AMD.

Not if you develop any respectable level of clue in your statements (not
that this seems likely to happen, from what I've seen): while I'm certainly
inclined to ensure that Itanic's deficiencies don't go unnoticed, I'm also
fair (you can even find a vigorous defense of Itanic2 and Xeon against
inflated Opteron hype that I began on September 16th in the "New Itanium
chips cost just $744" thread) - and I have no problems at all with Intel's
IA32 architecture save for the misrepresentations that fanboys like you make
about it.

- bill

[Robert Myers]

On Thu, 25 Sep 2003 14:20:39 -0600, "Judd" <IhateSpam@stopspam.com>
wrote:
"Bill Todd" <billtodd@metrocast.net> wrote in messagenews:48acndKC9_4tsu6iU-KYgA@metrocast.net... "Judd" <IhateSpam@stopspam.com> wrote in message news:21Fcb.55$oD4.29834@news.uswest.net... "Yousuf Khan" <bbbl67.spam@yahoo.com.nospam> wrote in message news:PV5bb.5762$Lnr1.5118@news01.bloor.is.net.cable.rogers.com... > http://www.theinquirer.net/?article=11670 > > Ace's Hardware seems to be seeing between 2-15% improvement from the2MB L3 > cache. > > Ace's will also be doing a head to head against processors from a "rival" > processor manufacturer in a couple of days, when their NDA expires.Stay > tuned. > Toms Hardware did a benchmark and the P4EE won on just about every benchmark over the highest rated A64 (the FX or whatever it is). Your rose-colored glasses need a new prescription: P4EE won only about2/3 of the tests - and but for its clean sweep of the MPEG and MP3 encoding tests would have won only about half of them.Back at it again as always, LOL. Every post I make about Intel is sure toget a Bill Todd response crying for AMD. Truth is, Intel is competingwithout Prescott and who would have thunk. Things will be interesting overthe next few months.
The subject line of your post is unattractive and inaccurate character
assassination. See his lengthy response to Rob Stow on 9/16/2003
unter the thread "New Itanium chips cost just $744".

I don't get the feeling that Intel is on Bill's list of most admired
computer chip manufacturers, but I have never known him even to be
selective in his presentation of facts, never mind to distort them, as
the terms "shill" and "apologist" would lead a reader to expect.

RM

[Tony Hill]

On Thu, 25 Sep 2003 10:50:07 -0600, "Judd" <IhateSpam@stopspam.com>
wrote:"Yousuf Khan" <bbbl67.spam@yahoo.com.nospam> wrote in messagenews:PV5bb.5762$Lnr1.5118@news01.bloor.is.net.cable.rogers.com... http://www.theinquirer.net/?article=11670 Ace's Hardware seems to be seeing between 2-15% improvement from the 2MBL3 cache. Ace's will also be doing a head to head against processors from a "rival" processor manufacturer in a couple of days, when their NDA expires. Stay tuned.Toms Hardware did a benchmark and the P4EE won on just about every benchmarkover the highest rated A64 (the FX or whatever it is). The P4 3.2 and theA64 were about even on the tests though Toms hardware claimed the FX wasvictorious (not sure how they came to that conclusion).

I don't think anyone knows how Tom's hardware manages to come up with
some of the conclusions that they do. Mostly it seems to do with what
company happens to be giving them the red-carpet treatment and who
took Tom out to the nicest restaurant.
It looks like Intelhas stemmed the tide for now and has time to release it's Prescott (noreason to hurry).

It seems to me that the Athlon64 3200+ and the P4 3.2C are well
matched at this time, while the Athlon64 FX 51 and the P4 EE 3.2GHz
are also about even. In each case sometimes one chip wins and
sometimes the other wins, but overall most people aren't likely to
notice the difference.

Then it just comes down to other features. I really like Intel's
Hyperthreading feature, and if you look at some multitasking tests
(always somewhat tricky to perform), the P4 almost always comes out on
top. On the other hand, AMD's 64-bit capabilities are nice and are
currently mostly unused. I've been surprised to see a number of
applications showing a good performance boost when going to 64-bits
which I had not expected. MP3 encoding, Div-X encoding and software
compression all seem like they might see a decent (greater than 10%)
boost in performance which I had not expected to see.

Personally, I see both the Athlon64 FX series and the P4EE chips as
being a waste of money. Both add a LOT to the price tag without
adding much to performance. Hmm, interesting, I just checked my
regular parts supplier (www.ncix.com, note: prices in Canadian $), and
they now list the Athlon64 3200+ as being in stock. What's more, it's
listed as being quite a bit cheaper than the 3.2GHz P4; $640 (~$450
US) for the Athlon64 vs. $998 (~$710 US) for the P4.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

[Telcontar]

> I don't think anyone knows how Tom's hardware manages to come up with some of the conclusions that they do. Mostly it seems to do with what company happens to be giving them the red-carpet treatment and who took Tom out to the nicest restaurant.

On a tangent not relating to the thread at all, sorry, but why do they
still call it Tom's? When was the last time anyone saw an article with
the good doctor's byline?

[Tony Hill]

On Fri, 26 Sep 2003 13:10:36 GMT, Telcontar <Telcontar@att.net> wrote: I don't think anyone knows how Tom's hardware manages to come up with some of the conclusions that they do. Mostly it seems to do with what company happens to be giving them the red-carpet treatment and who took Tom out to the nicest restaurant.On a tangent not relating to the thread at all, sorry, but why do theystill call it Tom's? When was the last time anyone saw an article withthe good doctor's byline?

They call it Tom's Hardware because it's a brand name that has good
recognition. Same reason why Intel still calls their chips "Pentium",
even though the Pentium 4 has virtually nothing in common with the
original Pentium.

Of course, I've personally found that quality of the articles on Tom's
Hardware has gone up slightly since Tom seems to no longer be involved
with things :>

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

[Judd]

"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in message
news:4b7713133964b87678338043acb17402@news.1usenet.com... On Thu, 25 Sep 2003 10:50:07 -0600, "Judd" <IhateSpam@stopspam.com> wrote:"Yousuf Khan" <bbbl67.spam@yahoo.com.nospam> wrote in messagenews:PV5bb.5762$Lnr1.5118@news01.bloor.is.net.cable.rogers.com... http://www.theinquirer.net/?article=11670 Ace's Hardware seems to be seeing between 2-15% improvement from the
2MBL3 cache. Ace's will also be doing a head to head against processors from a
"rival" processor manufacturer in a couple of days, when their NDA expires.
Stay tuned.Toms Hardware did a benchmark and the P4EE won on just about every
benchmarkover the highest rated A64 (the FX or whatever it is). The P4 3.2 and
theA64 were about even on the tests though Toms hardware claimed the FX wasvictorious (not sure how they came to that conclusion). I don't think anyone knows how Tom's hardware manages to come up with some of the conclusions that they do. Mostly it seems to do with what company happens to be giving them the red-carpet treatment and who took Tom out to the nicest restaurant. It looks like Intelhas stemmed the tide for now and has time to release it's Prescott (noreason to hurry). It seems to me that the Athlon64 3200+ and the P4 3.2C are well matched at this time, while the Athlon64 FX 51 and the P4 EE 3.2GHz are also about even. In each case sometimes one chip wins and sometimes the other wins, but overall most people aren't likely to notice the difference. Then it just comes down to other features. I really like Intel's Hyperthreading feature, and if you look at some multitasking tests (always somewhat tricky to perform), the P4 almost always comes out on top. On the other hand, AMD's 64-bit capabilities are nice and are currently mostly unused. I've been surprised to see a number of applications showing a good performance boost when going to 64-bits which I had not expected. MP3 encoding, Div-X encoding and software compression all seem like they might see a decent (greater than 10%) boost in performance which I had not expected to see. Personally, I see both the Athlon64 FX series and the P4EE chips as being a waste of money. Both add a LOT to the price tag without adding much to performance. Hmm, interesting, I just checked my regular parts supplier (www.ncix.com, note: prices in Canadian $), and they now list the Athlon64 3200+ as being in stock. What's more, it's listed as being quite a bit cheaper than the 3.2GHz P4; $640 (~$450 US) for the Athlon64 vs. $998 (~$710 US) for the P4.

I agree that there is a lot to like about both. As for price point, I would
expect to see the price of the Pentiums go down in the very near future.
They (Tom's hardware) did a price comparison of all the systems they put
together and they were very similar. I'm curious to see what's in store for
Prescott. For me personally, it's time to get a new system but I'm not sure
whether to get one now or wait (always the baited question). I'm a fan of
dual CPU's but if Prescott has improved hyperthreading, then perhaps I'll go
for the single CPU system for the first time in 10 years. The 64-bit will
come in handy one day, but for now, the AMD system's biggest advantage is
their fast memory subsystem and excellent price/performance.

[Judd]

"Carlo Razzeto" <crazzeto@hotmail.com> wrote in message
news:jPidnXEl4cIB9u6iU-KYuA@comcast.com... "Judd" <IhateSpam@stopspam.com> wrote in message news:21Fcb.55$oD4.29834@news.uswest.net... Toms Hardware did a benchmark and the P4EE won on just about every benchmark over the highest rated A64 (the FX or whatever it is). The P4 3.2 and
the A64 were about even on the tests though Toms hardware claimed the FX was victorious (not sure how they came to that conclusion). It looks like Intel has stemmed the tide for now and has time to release it's Prescott (no reason to hurry). You know what the great thing about benchmarks are? You can prove anything you want to prove! For every Tom's Hardware type site that found that the P4EE was the clear winner, there was another site such and Anandtech.com that found AMD64 to be the winner. In the end I think the situation
remains the same... People should be buying the best processor for the job they
want it to do. And for get about stupid allegiances to particular platforms. Carlo

So longtime AMD proponent Toms Hardware is now favoring Intel while
Anandtech is still in AMD's camp. Interesting...

[Judd]

"Carlo Razzeto" <crazzeto@hotmail.com> wrote in message
news:jPidnXEl4cIB9u6iU-KYuA@comcast.com... "Judd" <IhateSpam@stopspam.com> wrote in message news:21Fcb.55$oD4.29834@news.uswest.net... Toms Hardware did a benchmark and the P4EE won on just about every benchmark over the highest rated A64 (the FX or whatever it is). The P4 3.2 and
the A64 were about even on the tests though Toms hardware claimed the FX was victorious (not sure how they came to that conclusion). It looks like Intel has stemmed the tide for now and has time to release it's Prescott (no reason to hurry). You know what the great thing about benchmarks are? You can prove anything you want to prove! For every Tom's Hardware type site that found that the P4EE was the clear winner, there was another site such and Anandtech.com that found AMD64 to be the winner. In the end I think the situation
remains the same... People should be buying the best processor for the job they
want it to do. And for get about stupid allegiances to particular platforms. Carlo

By the way, checked out anandtech's site and didn't see a comparison to
P4EE, just one to P43.0c. I did see a link to x86-secret.com which showed
benchmarks between the two but did not see the conclusion of AMD winning.
In fact, from their graphics, they each won about 1/2 the tests (Intel won
like 1 or 2 more or something).

http://translate.google.com/translate?sourceid=navclient-menuext&hl=en&u=http%3A%2F%2Fwww%2Ex86%2Dsecret%2Ecom%2Fpopups%2Farticleswindow%2Ephp%3Fid%3D91

From this in translation, it says:
"This said, INTEL answered the evil by the evil and Pentium 4 ' EE' is a
success in term of performances. Catching up with Athlon 64 FX in all the
tests (except for UT2003 in BotMatch) and exceeding it, sometimes largely,
in others, Pentium 4 ' EE' are as powerful as expensive and inalienable"

Actually seems like they are saying the same thing as Tom's Site.

[Edmund]

On Fri, 26 Sep 2003 13:44:51 -0600, "Judd" <IhateSpam@stopspam.com>
wrote:
together and they were very similar. I'm curious to see what's in store forPrescott. For me personally, it's time to get a new system but I'm not sure

Prescott 2.8GHz...
http://www.oc.com.tw/article/0309/readgoodarticle.asp?id=1974

[Keith R. Williams]

In article <tI0db.658$kb5.26170@news.uswest.net>,
IhateSpam@stopspam.com says... "Carlo Razzeto" <crazzeto@hotmail.com> wrote in message news:jPidnXEl4cIB9u6iU-KYuA@comcast.com... "Judd" <IhateSpam@stopspam.com> wrote in message news:21Fcb.55$oD4.29834@news.uswest.net... Toms Hardware did a benchmark and the P4EE won on just about every benchmark over the highest rated A64 (the FX or whatever it is). The P4 3.2 and the A64 were about even on the tests though Toms hardware claimed the FX was victorious (not sure how they came to that conclusion). It looks like Intel has stemmed the tide for now and has time to release it's Prescott (no reason to hurry). You know what the great thing about benchmarks are? You can prove anything you want to prove! For every Tom's Hardware type site that found that the P4EE was the clear winner, there was another site such and Anandtech.com that found AMD64 to be the winner. In the end I think the situation remains the same... People should be buying the best processor for the job they want it to do. And for get about stupid allegiances to particular platforms. Carlo So longtime AMD proponent Toms Hardware is now favoring Intel while Anandtech is still in AMD's camp. Interesting...

You either don't have a clue about Dr. Tom, or your haven't been
paying attention. Likely both!

Why *anyone* would listen to what he (or anyone writing for his
site) has to say is beyond me! He's for sale to the lowest bidder
(damn, even a first-class ticket and a dinner rubbing elbows has
impressed the nitwit).

--
Keith

[root]

Tony Hill <hilla_nospam_20@yahoo.ca> wrote:It seems to me that the Athlon64 3200+ and the P4 3.2C are wellmatched at this time, while the Athlon64 FX 51 and the P4 EE 3.2GHzare also about even. ...

Indeed.
Then it just comes down to other features. I really like Intel'sHyperthreading feature, ... AMD's 64-bit capabilities are nice and arecurrently mostly unused. I've been surprised to see a number ofapplications showing a good performance boost when going to 64-bitswhich I had not expected. MP3 encoding, Div-X encoding

Why not? bit operations and multiplications are always the wider the
better if you can do them in equal time -- you have fewer to do now.
Personally, I see both the Athlon64 FX series and the P4EE chips asbeing a waste of money. ... Hmm, interesting, I just checked ...Athlon64 3200+ as being in stock ... cheaper than the 3.2GHz P4; $450US for the Athlon64 vs. (~$710 US) for the P4.

How would a P4 3.2GHz EE plus the intel 875 chipset compare with a pair
of Opteron 240's on (say) the Tyan K8S or K8W in terms of productivity?
Yes, I know that the latter runs to about $1200.

[Carlo Razzeto]

"Judd" <IhateSpam@stopspam.com> wrote in message
news:J_0db.661$kb5.26592@news.uswest.net... "Carlo Razzeto" <crazzeto@hotmail.com> wrote in message news:jPidnXEl4cIB9u6iU-KYuA@comcast.com... By the way, checked out anandtech's site and didn't see a comparison to P4EE, just one to P43.0c. I did see a link to x86-secret.com which showed benchmarks between the two but did not see the conclusion of AMD winning. In fact, from their graphics, they each won about 1/2 the tests (Intel won like 1 or 2 more or something).

You obviously didn't read the "AMD Athlon 64 & Athlon 64 FX - It's Judgement
Day" Artical written by anand him self... Or if you did you didn't interpit
"P4 EE" the same way I did... Not sure which it is...

Carlo

[Tony Hill]

On 27 Sep 2003 03:10:01 GMT, root@precision.moscito.org (root) wrote:Tony Hill <hilla_nospam_20@yahoo.ca> wrote:It seems to me that the Athlon64 3200+ and the P4 3.2C are wellmatched at this time, while the Athlon64 FX 51 and the P4 EE 3.2GHzare also about even. ...Indeed.Then it just comes down to other features. I really like Intel'sHyperthreading feature, ... AMD's 64-bit capabilities are nice and arecurrently mostly unused. I've been surprised to see a number ofapplications showing a good performance boost when going to 64-bitswhich I had not expected. MP3 encoding, Div-X encodingWhy not? bit operations and multiplications are always the wider thebetter if you can do them in equal time -- you have fewer to do now.

To make use of wider bits, you need to actually be using the values.
You can't pack two 32-bit values in a 64-bit register and be done with
it, it just doesn't work like that. You actually need to be using
64-bit integers to see a benefit from the 64-bitness, and that means
that your integer values have to have the possibility of being larger
than 4 billion. For Div-X in particular I figured that most would be
handled by the floating point unit anyway, which is unchanged in AMD64
as compared to IA32.

It's quite possible, perhaps even likely, that the real difference is
coming from the double the number of registers rather than doubling
the width of them. This is rather unrelated to AMD64 being a 64-bit
instruction set, it was just a convenient time to fix a long-lasting
problem with x86.
Personally, I see both the Athlon64 FX series and the P4EE chips asbeing a waste of money. ... Hmm, interesting, I just checked ...Athlon64 3200+ as being in stock ... cheaper than the 3.2GHz P4; $450US for the Athlon64 vs. (~$710 US) for the P4.How would a P4 3.2GHz EE plus the intel 875 chipset compare with a pairof Opteron 240's on (say) the Tyan K8S or K8W in terms of productivity?Yes, I know that the latter runs to about $1200.

Depends in what you're planning on doing with the machine. For me, I
would probably prefer the Opterons. For a gamer, the P4 EE would be
better.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

[Tony Hill]

On Fri, 26 Sep 2003 13:44:51 -0600, "Judd" <IhateSpam@stopspam.com>
wrote: Personally, I see both the Athlon64 FX series and the P4EE chips as being a waste of money. Both add a LOT to the price tag without adding much to performance. Hmm, interesting, I just checked my regular parts supplier (www.ncix.com, note: prices in Canadian $), and they now list the Athlon64 3200+ as being in stock. What's more, it's listed as being quite a bit cheaper than the 3.2GHz P4; $640 (~$450 US) for the Athlon64 vs. $998 (~$710 US) for the P4.I agree that there is a lot to like about both. As for price point, I wouldexpect to see the price of the Pentiums go down in the very near future.They (Tom's hardware) did a price comparison of all the systems they puttogether and they were very similar.

And as usual, Tom's lackey came up with some really odd-ball
statements about price. Like why does the memory for the Athlon64
3200+ cost more than the memory for the AthlonXP 3200+, which in turn
costs more than the memory for the P4 (C and EE) 3.2GHz? They all use
unbuffered, DDR400 memory, so why use different memory (or at least
have different prices) for each?

Also, his price guide includes an extra $94 on the AMD systems for an
add-in Serial ATA RAID card, which likely has little relevance for
most users (if they were needing SATA RAID on an AMD board, they would
probably buy a board with it built in, as many exist for the AthlonXP
and a few even exist for the Athlon64).

I also don't understand why every processor has a $50 cooler added on
to the price, despite the fact that he's using the price for retail
box processors which come with a cooler.
I'm curious to see what's in store forPrescott. For me personally, it's time to get a new system but I'm not surewhether to get one now or wait (always the baited question). I'm a fan ofdual CPU's but if Prescott has improved hyperthreading, then perhaps I'll gofor the single CPU system for the first time in 10 years. The 64-bit willcome in handy one day, but for now, the AMD system's biggest advantage istheir fast memory subsystem and excellent price/performance.

I agree. Fortunately or unfortunately, depending on how you look at
it, I'm not in the market for a new machine just yet (gotta find a
job, an apartments and a car first :> ), so I'll have a bit of time to
sort things out before deciding. At the moment I would probably lean
towards Intel's P4, especially if the Prescott does improve
hyperthreading and is available at a reasonable price. Unfortunately
the latter isn't likely to occur until Feb. or March of next year.
The first Prescott chips now won't be out until December apparently,
and initially it will only be at 3.2 or 3.4GHz and be quite expensive.

Ohh well, the next upgrade for me will be a new hard drive anyway,
gotta replace that IBM Deskstar 75GXP that, surprise, surprise, has
died on me :<

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

[Yousuf Khan]

"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in message
news:74a202e1b3c3cf909842251447091c28@news.1usenet.com...Why not? bit operations and multiplications are always the wider thebetter if you can do them in equal time -- you have fewer to do now. To make use of wider bits, you need to actually be using the values. You can't pack two 32-bit values in a 64-bit register and be done with it, it just doesn't work like that.

You've forgotten about the SIMD instructions, i.e. MMX all of the way upto
SSE2.

Yousuf Khan

[Tony Hill]

On Sat, 27 Sep 2003 07:35:46 GMT, "Yousuf Khan"
<removethisspam.bjsk90.removethispam@hotmail.com> wrote:"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in messagenews:74a202e1b3c3cf909842251447091c28@news.1usenet.com... To make use of wider bits, you need to actually be using the values. You can't pack two 32-bit values in a 64-bit register and be done with it, it just doesn't work like that.You've forgotten about the SIMD instructions, i.e. MMX all of the way uptoSSE2.

True, but that's a whole other can of worms right there, and has no
real bearing on the subject of the performance of the Athlon64 in
32-bit mode vs. 64-bit mode.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

[ZOD]

> even though the Pentium 4 has virtually nothing in common with the original Pentium.

ROFL....only that x86 stuff.....hehe

[Tony Hill]

On Sun, 28 Sep 2003 16:43:32 GMT, "ZOD" <ZOD@ZOD.com> wrote: even though the Pentium 4 has virtually nothing in common with the original Pentium.ROFL....only that x86 stuff.....hehe

Yup, that same x86 stuff that the 386 had. Does that mean that the
386 and the Pentium 4 are in any way similar chips?

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

[Judd]

> You either don't have a clue about Dr. Tom, or your haven't been paying attention. Likely both! Why *anyone* would listen to what he (or anyone writing for his site) has to say is beyond me! He's for sale to the lowest bidder (damn, even a first-class ticket and a dinner rubbing elbows has impressed the nitwit).

Yes, it's all a conspiracy Keith.

Judd

[George Macdonald]

On Sat, 27 Sep 2003 07:12:02 GMT, Tony Hill <hilla_nospam_20@yahoo.ca>
wrote:
On 27 Sep 2003 03:10:01 GMT, root@precision.moscito.org (root) wrote:Tony Hill <hilla_nospam_20@yahoo.ca> wrote:It seems to me that the Athlon64 3200+ and the P4 3.2C are wellmatched at this time, while the Athlon64 FX 51 and the P4 EE 3.2GHzare also about even. ...Indeed.Then it just comes down to other features. I really like Intel'sHyperthreading feature, ... AMD's 64-bit capabilities are nice and arecurrently mostly unused. I've been surprised to see a number ofapplications showing a good performance boost when going to 64-bitswhich I had not expected. MP3 encoding, Div-X encodingWhy not? bit operations and multiplications are always the wider thebetter if you can do them in equal time -- you have fewer to do now.To make use of wider bits, you need to actually be using the values.

I think he means bit operations: boolean, shifting etc. If you have huge
arrays of bits which need such operations, 64-bit is a huge benefit.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

[Tony Hill]

On Mon, 29 Sep 2003 19:41:36 GMT, fammacd=!SPAM^nothanks@tellurian.com
(George Macdonald) wrote:To make use of wider bits, you need to actually be using the values.I think he means bit operations: boolean, shifting etc. If you have hugearrays of bits which need such operations, 64-bit is a huge benefit.

Bit operations are generally VERY rare breeds in this day and age,
mainly because they don't really offer you anything over integer
operations. The chance of having more than 32 boolean variables in a
single application and being used in a relatively short period of time
(such that they aren't been pushed out of renamed registers or at the
very least the L1 cache) is pretty darn slim if you ask me.

The only case where I've seen use of a lots of boolean stuff and
shifting is in cryptography, and that's an area that has already been
discussed as benefiting strongly from 64-bit processing.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

[Keith R. Williams]

In article <h9_db.28$qU6.25664@news.uswest.net>,
IhateSpam@stopspam.com says... You either don't have a clue about Dr. Tom, or your haven't been paying attention. Likely both! Why *anyone* would listen to what he (or anyone writing for his site) has to say is beyond me! He's for sale to the lowest bidder (damn, even a first-class ticket and a dinner rubbing elbows has impressed the nitwit). Yes, it's all a conspiracy Keith.

You haven't a clue, eh kid? DeanK has documented some of his
inanities. You might wish to search the archives of this group
before showing your green side.

--
Keith

[Carlo Razzeto]

"Keith R. Williams" <krw@attglobal.net> wrote in message
news:MPG.19e2bb3b7ec8c94098a73e@enews.newsguy.com... In article <h9_db.28$qU6.25664@news.uswest.net>, IhateSpam@stopspam.com says... You haven't a clue, eh kid? DeanK has documented some of his inanities. You might wish to search the archives of this group before showing your green side. -- Keith

Yeah... Unfortunetly I don't have links... But I've seen him declare a
product a winnner (even AMD's) in a particular benchmark when at least
according to the diagram posted to the web site, it clearly was not.... Dr.
Tom is insane...

Carlo

[Judd]

You haven't a clue, eh kid? DeanK has documented some of his inanities. You might wish to search the archives of this group before showing your green side.

Are you Mulder or Scully? I've seen him give some interesting conclusions
on his benchmarks that I would not have come to based on the figures, but
that's about it. Of course, I'm clueless and green. LMAO! Some of you
guys are crackups.

Judd

[George Macdonald]

On Mon, 29 Sep 2003 22:07:35 GMT, Tony Hill <hilla_nospam_20@yahoo.ca>
wrote:
On Mon, 29 Sep 2003 19:41:36 GMT, fammacd=!SPAM^nothanks@tellurian.com(George Macdonald) wrote:To make use of wider bits, you need to actually be using the values.I think he means bit operations: boolean, shifting etc. If you have hugearrays of bits which need such operations, 64-bit is a huge benefit.Bit operations are generally VERY rare breeds in this day and age,mainly because they don't really offer you anything over integeroperations. The chance of having more than 32 boolean variables in asingle application and being used in a relatively short period of time(such that they aren't been pushed out of renamed registers or at thevery least the L1 cache) is pretty darn slim if you ask me.

Tha's a kinda sweeping statement to me - IME bit maps have come in handy
from time to time. Not sure what the 32 variables has to do with it.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

[Bill Todd]

"George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote in message
news:3f79e2ca.26725883@news.tellurian.com... On Mon, 29 Sep 2003 22:07:35 GMT, Tony Hill <hilla_nospam_20@yahoo.ca> wrote:On Mon, 29 Sep 2003 19:41:36 GMT, fammacd=!SPAM^nothanks@tellurian.com(George Macdonald) wrote:>To make use of wider bits, you need to actually be using the values.I think he means bit operations: boolean, shifting etc. If you have
hugearrays of bits which need such operations, 64-bit is a huge benefit.Bit operations are generally VERY rare breeds in this day and age,mainly because they don't really offer you anything over integeroperations. The chance of having more than 32 boolean variables in asingle application and being used in a relatively short period of time(such that they aren't been pushed out of renamed registers or at thevery least the L1 cache) is pretty darn slim if you ask me. Tha's a kinda sweeping statement to me - IME bit maps have come in handy from time to time.

Absolutely.
Not sure what the 32 variables has to do with it.

Perhaps it was in reference to any potential advantage of moving to 64 bits
for bit-booleans.

A couple of other observations are that 1) booleans aren't always
independent (e.g., one may wish to change more than one at a time) and 2)
structures that store booleans (at least large numbers of booleans) may
benefit noticeably from occupying as few cache lines as possible. Perhaps
not major considerations, but not necessarily negligible either.

- bill

[George Macdonald]

On Tue, 30 Sep 2003 11:00:18 -0400, "Carlo Razzeto" <crazzeto@hotmail.com>
wrote:
"Keith R. Williams" <krw@attglobal.net> wrote in messagenews:MPG.19e2bb3b7ec8c94098a73e@enews.newsguy.com... In article <h9_db.28$qU6.25664@news.uswest.net>, IhateSpam@stopspam.com says... You haven't a clue, eh kid? DeanK has documented some of his inanities. You might wish to search the archives of this group before showing your green side. -- KeithYeah... Unfortunetly I don't have links... But I've seen him declare aproduct a winnner (even AMD's) in a particular benchmark when at leastaccording to the diagram posted to the web site, it clearly was not.... Dr.Tom is insane...

Oh yeah the performance that just "slaughters" the competition by being
barely faster on one test - the "hyperbolic Tomvoid".:-)

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

[Carlo Razzeto]

"George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote in message
news:3f7b2d63.28492820@news.tellurian.com... On Tue, 30 Sep 2003 11:00:18 -0400, "Carlo Razzeto" <crazzeto@hotmail.com> wrote:"Keith R. Williams" <krw@attglobal.net> wrote in messagenews:MPG.19e2bb3b7ec8c94098a73e@enews.newsguy.com... In article <h9_db.28$qU6.25664@news.uswest.net>, IhateSpam@stopspam.com says... Oh yeah the performance that just "slaughters" the competition by being barely faster on one test - the "hyperbolic Tomvoid".:-) Rgds, George Macdonald "Just because they're paranoid doesn't mean you're not psychotic" - Who,
me??

I've seen worse... I wish I had the link... I remember one particular
benchmark where Tom declared the Athlon the winner and it hadden't won the
benchmark... I mean I've always been supportive of AMD, espeacially since
AMD based systems I could afford to bulid back in HS... But com'on... You
can't display a graph comparing two products and declaring the obviouse
loser on that particular graph the winner.

Carlo

[David Schwartz]

"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in message
news:9444831a0d4d28ba6750fa7c39df1891@news.1usenet.com...
On Mon, 29 Sep 2003 19:41:36 GMT, fammacd=!SPAM^nothanks@tellurian.com
(George Macdonald) wrote:To make use of wider bits, you need to actually be using the values.
I think he means bit operations: boolean, shifting etc. If you have hugearrays of bits which need such operations, 64-bit is a huge benefit.
Bit operations are generally VERY rare breeds in this day and age, mainly because they don't really offer you anything over integer operations.

Generally most bit operations will be implemented as integer operations.
For example, if you have 12 single bit flags associated with an object,
you'll generally store them in a single 32-bit integer and manipulate them
by ands and ors.
The chance of having more than 32 boolean variables in a single application and being used in a relatively short period of time (such that they aren't been pushed out of renamed registers or at the very least the L1 cache) is pretty darn slim if you ask me.

Probably. It's not that unusual to have more than 32 booleans associated
with a single object. It's common in servers that deal with complex objects
that have lots of properties (for example, a channel in a chat server). I
don't think it's that common to manipulate large numbers of bit flags at the
same time though. Generally, you'll be setting one bit or checking one bit.
For bits holding flags, rotations and other operations that could benefit
from handling 64 bits at a time don't make much sense.
The only case where I've seen use of a lots of boolean stuff and shifting is in cryptography, and that's an area that has already been discussed as benefiting strongly from 64-bit processing.

In cryptography, it's not unusual to treat data as if it were an array
of booleans. In that case, handling more bits at a time has obvious
advantages. Cryptography also deals with large integers, and being able to
have half as many 64-bit chunks is probably going to be faster than twice as
many 32-bit chunks.

Some other applications do require encoding data. Even manipulating
character strings may be optimizable into manipulating 64-bit chunks instead
of 32-bit chunks. Calculating checksums may be similarly optimizable.

I think overall though, 64-bit machines won't boost performance very
much just because they can handle 64-bits at a time. 8-bit numbers are too
small for almost anything. 16-bit numbers are large enough for most things.
32-bit numbers are large enough for nearly anything. So each boost in bit
width has meant more and more things could be handled by native-width
integers. But the boost from 32-bit to 64-bit doesn't have much left to
include. You rarely deal with more than 2 billion of anything.

DS

[Keith R. Williams]

In article <Xnmeb.404$W7.41074@news.uswest.net>,
IhateSpam@stopspam.com says... You haven't a clue, eh kid? DeanK has documented some of his inanities. You might wish to search the archives of this group before showing your green side. Are you Mulder or Scully?

No (I guess you can't read either), but I've been around the Tom
block a few times. His site is a waste of bits.
I've seen him give some interesting conclusions on his benchmarks that I would not have come to based on the figures, but that's about it.

"Interesting" is one way you could put it. It's not exactly the
word I'd use, at least without quotes.
Of course, I'm clueless and green. LMAO!
Apparently you are.
Some of you guys are crackups.

Look in the mirror.

--
Keith

[Dean Kent]

"Judd" <IhateSpam@stopspam.com> wrote in message
news:Xnmeb.404$W7.41074@news.uswest.net... Are you Mulder or Scully? I've seen him give some interesting conclusions on his benchmarks that I would not have come to based on the figures, but that's about it. Of course, I'm clueless and green. LMAO! Some of you guys are crackups.

FWIW, I was his very first advertiser and knew him personally until he got
mad at me for writing articles for Sharkey Extreme. What his ethics are
today, I haven't a clue. But, when all is said and done "Dammit Jim, he's a
doctor not an engineer!". :-).

Regards,
Dean
Judd

[Dean Kent]

"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in message
news:9444831a0d4d28ba6750fa7c39df1891@news.1usenet.com... Bit operations are generally VERY rare breeds in this day and age, mainly because they don't really offer you anything over integer operations. The chance of having more than 32 boolean variables in a single application and being used in a relatively short period of time (such that they aren't been pushed out of renamed registers or at the very least the L1 cache) is pretty darn slim if you ask me. The only case where I've seen use of a lots of boolean stuff and shifting is in cryptography, and that's an area that has already been discussed as benefiting strongly from 64-bit processing.

Gosh, we use them quite a bit where I work... but then, we are also a very
rare breed these days.

I don't get the 32 variables comment. Are you implying that the only way to
reference a bit is if it is part of a fullword?

Regards,
Dean
------------- Tony Hill hilla <underscore> 20 <at> yahoo <dot> ca

[George Macdonald]

On Sat, 04 Oct 2003 04:59:30 GMT, "Dean Kent" <dkent@realworldtech.com>
wrote:
"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in messagenews:9444831a0d4d28ba6750fa7c39df1891@news.1usenet.com... Bit operations are generally VERY rare breeds in this day and age, mainly because they don't really offer you anything over integer operations. The chance of having more than 32 boolean variables in a single application and being used in a relatively short period of time (such that they aren't been pushed out of renamed registers or at the very least the L1 cache) is pretty darn slim if you ask me. The only case where I've seen use of a lots of boolean stuff and shifting is in cryptography, and that's an area that has already been discussed as benefiting strongly from 64-bit processing.Gosh, we use them quite a bit where I work... but then, we are also a veryrare breed these days.

I'm sure there's lots of places where bit array masking and other such
operatons are handy. I've used it and know others who have used it
extensively too.
I don't get the 32 variables comment. Are you implying that the only way toreference a bit is if it is part of a fullword?

Yep - I think he means with a 32-bit word you have 32 single bit
booleans... and with PL/1, I guess you can even declare them thus.:-)

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

[Telcontar]

Dean Kent wrote:
FWIW, I was his very first advertiser and knew him personally until he got mad at me for writing articles for Sharkey Extreme. What his ethics are today, I haven't a clue. But, when all is said and done "Dammit Jim, he's a doctor not an engineer!". :-). Regards, Dean

I had a chuckle at the site the other day, In the middle of an article
on the new Radeon card he pops in and editorializes spanking both Nvidia
and Ati. I couldn't help but wonder if he read the thread and decided to
make an appearence...<g> I don't remember his hair being that vivid gold
color...

[Carlo Razzeto]

"George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote in message
news:3f7eaa4c.881193@news.tellurian.com... On Sat, 04 Oct 2003 04:59:30 GMT, "Dean Kent" <dkent@realworldtech.com> wrote:"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in messagenews:9444831a0d4d28ba6750fa7c39df1891@news.1usenet.com...Gosh, we use them quite a bit where I work... but then, we are also a
veryrare breed these days. I'm sure there's lots of places where bit array masking and other such operatons are handy. I've used it and know others who have used it extensively too.

I've used them to do a GA before... They really are handy if you want to
code for memory efficiency.... But then again, it doesn't take a lot of
memory to store the basic data needed to run a GA. In mine it was a pointer
to an unsigned, with enough memory allocated to store the number of bit's
required for the GA run, a double, two ints, and one stadic array of two
int's... To run the New York City Pipes sim it took 32 bytes... If I had
gone with an array of shorts, or an array of C++ bools, it wouldn't have
been too much worse when you consider the average machine in the out dated
(hardware wise) beowulf cluster I was running this on had 32M of memory.
I don't get the 32 variables comment. Are you implying that the only way
toreference a bit is if it is part of a fullword? Yep - I think he means with a 32-bit word you have 32 single bit booleans... and with PL/1, I guess you can even declare them thus.:-) Rgds, George Macdonald "Just because they're paranoid doesn't mean you're not psychotic" - Who,
me??

[David Schwartz]

"Dean Kent" <dkent@realworldtech.com> wrote in message
news:Sssfb.11443$uc.4193@newssvr25.news.prodigy.com...
I don't get the 32 variables comment. Are you implying that the only way
to reference a bit is if it is part of a fullword?

Since a bit always is part of a fullword, your question doesn't really
make sense.

DS

[Dean Kent]

"David Schwartz" <davids@webmaster.com> wrote in message
news:blmkg0$l2p$1@nntp.webmaster.com... "Dean Kent" <dkent@realworldtech.com> wrote in message news:Sssfb.11443$uc.4193@newssvr25.news.prodigy.com... I don't get the 32 variables comment. Are you implying that the only
way to reference a bit is if it is part of a fullword? Since a bit always is part of a fullword, your question doesn't really make sense.

Really. How come I can define a byte and reference the individual bits
within it? I guess my assembler just isn't as smart as you... :-).

Regards,
Dean
DS

[Dean Kent]

"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in message
news:540b5708147341d506d4b8ef5edf7e91@news.1usenet.com... Maybe I'm missing something here though. Is there another way in which having 64-bit registers would help boolean operations vs. a chip with 32-bit registers?

I have absolutely no idea how register width has anything to do with boolean
operations, unless someone is considering things like 'shift' (or roll, or
whatever it might be in another language) to be boolean and want to operate
on larger than 32-bit values. I only saw the comment about how rare it is
to do boolean/bit manipulation and thought I would make my dinosaur rear end
noticed...

Regards,
Dean
------------- Tony Hill hilla <underscore> 20 <at> yahoo <dot> ca

[Tony Hill]

On Sat, 04 Oct 2003 04:59:30 GMT, "Dean Kent"
<dkent@realworldtech.com> wrote:"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in messagenews:9444831a0d4d28ba6750fa7c39df1891@news.1usenet.com... Bit operations are generally VERY rare breeds in this day and age, mainly because they don't really offer you anything over integer operations. The chance of having more than 32 boolean variables in a single application and being used in a relatively short period of time (such that they aren't been pushed out of renamed registers or at the very least the L1 cache) is pretty darn slim if you ask me. The only case where I've seen use of a lots of boolean stuff and shifting is in cryptography, and that's an area that has already been discussed as benefiting strongly from 64-bit processing.Gosh, we use them quite a bit where I work... but then, we are also a veryrare breed these days.

That's an understatement! Ohh, err.. yeah mean about the programming
thing :>
I don't get the 32 variables comment. Are you implying that the only way toreference a bit is if it is part of a fullword?

I was trying to understand how going from 32-bit to 64-bit registers
would somehow improve performance of boolean operations. The only
thing I can see, off the top of my head, is if you have an array of
booleans that is more than 32-bits in length, ie not just a couple of
boolean values here and there.

Maybe I'm missing something here though. Is there another way in
which having 64-bit registers would help boolean operations vs. a chip
with 32-bit registers?

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

[David Schwartz]

"Dean Kent" <dkent@realworldtech.com> wrote in message
news:A9Kfb.11764$3W.2191@newssvr25.news.prodigy.com...
Since a bit always is part of a fullword, your question doesn't
really make sense.
Really. How come I can define a byte and reference the individual bits within it? I guess my assembler just isn't as smart as you... :-).

Believe it or not, there are three other bytes next to that one, the set
of which can be called a 'fullword'. ;)

DS

[Keith R. Williams]

In article <blppg6$iit$1@nntp.webmaster.com>,
davids@webmaster.com says... "Dean Kent" <dkent@realworldtech.com> wrote in message news:A9Kfb.11764$3W.2191@newssvr25.news.prodigy.com... Since a bit always is part of a fullword, your question doesn't really make sense. Really. How come I can define a byte and reference the individual bits within it? I guess my assembler just isn't as smart as you... :-). Believe it or not, there are three other bytes next to that one, the set of which can be called a 'fullword'. ;)

Believe it or not (speaking post P5, x86 here), there are (at
least) three more "fullwords" next to that one. So?

--
Keith

[David Schwartz]

"Keith R. Williams" <krw@attglobal.net> wrote in message
news:MPG.19ea39e23ad4129b98a761@enews.newsguy.com...
Believe it or not, there are three other bytes next to that one, the
set of which can be called a 'fullword'. ;)
Believe it or not (speaking post P5, x86 here), there are (at least) three more "fullwords" next to that one. So?

So there's no such thing as a bit that's not part of a fullword.

DS

[David Schwartz]

"David Schwartz" <davids@webmaster.com> wrote in message
news:blq3l9$ol7$1@nntp.webmaster.com...
So there's no such thing as a bit that's not part of a fullword.

The point is that if you're using a high-level language, bit operations
may be converted into integer operations and vice-versa. The compiler will
choose the more efficient form. So you really don't know (unless you look at
the assembler output, which can vary based on optimization settings and so
on) whether you're doing bit operations or integer operations.

DS

[Dean Kent]

"David Schwartz" <davids@webmaster.com> wrote in message
news:blppg6$iit$1@nntp.webmaster.com... "Dean Kent" <dkent@realworldtech.com> wrote in message news:A9Kfb.11764$3W.2191@newssvr25.news.prodigy.com... Really. How come I can define a byte and reference the individual bits within it? I guess my assembler just isn't as smart as you... :-). Believe it or not, there are three other bytes next to that one, the
set of which can be called a 'fullword'. ;)

Are you absolutely certain? Are you claiming that I can only define a
byte in my program that is aligned on a fullword? I find that awfully
odd, since I can look in the dump and see that it is not. I can reference
that byte without referencing any other bytes, and those other bytes can
contain data with a different data format (assuming that they don't need to
be fullword aligned. FWIW, since nobody has yet made any specific mention
of ISA, it may very well be that we are talking about two different ones, so
your 'rules' may not apply to me, and vice-versa.

Consider the following:

DS 0F
Byte1 DS XL1
Flag1 EQU X'80'
Flag2 EQU X'40'
Flag3 EQU X'20'
Flag4 EQU X'10'
Flag5 EQU X'08'
Flag6 EQU X'04'
Flag7 EQU X'02'
Flag8 EQU X'01'
Byte1 DS CL1
HW1 DS H

Now, are you going to tell me that I cannot do what I just did? I am
looking at some working code right now that allows me to flip the bits on
the first byte, store a character in the second, and store a halfword binary
in the next two. How is it I can do that?

Regards,
Dean

DS

[Dean Kent]

"David Schwartz" <davids@webmaster.com> wrote in message
news:blq3l9$ol7$1@nntp.webmaster.com... So there's no such thing as a bit that's not part of a fullword.

So, you really don't know what you are talking about then?

Regards,
Dean
DS

[David Schwartz]

"Dean Kent" <dkent@realworldtech.com> wrote in message
news:fl1gb.11946$ct3.6728@newssvr25.news.prodigy.com...
"David Schwartz" <davids@webmaster.com> wrote in message news:blppg6$iit$1@nntp.webmaster.com...
"Dean Kent" <dkent@realworldtech.com> wrote in message news:A9Kfb.11764$3W.2191@newssvr25.news.prodigy.com...
Really. How come I can define a byte and reference the individual
bits within it? I guess my assembler just isn't as smart as you... :-).
Believe it or not, there are three other bytes next to that one, the set of which can be called a 'fullword'. ;)
Are you absolutely certain?

Yes.
Are you claiming that I can only define a byte in my program that is aligned on a fullword?

No. A fullword consists of more than one byte.
I find that awfully odd, since I can look in the dump and see that it is not.

What exactly are you seeing? Show me what a byte that is not part of a
fullword looks like.
I can reference that byte without referencing any other bytes, and those other bytes can contain data with a different data format (assuming that they don't need
to be fullword aligned.

Sure you can. But you can also reference that byte as part of the
fullword that contains it.
FWIW, since nobody has yet made any specific mention of ISA, it may very well be that we are talking about two different ones,
so your 'rules' may not apply to me, and vice-versa. Consider the following: DS 0F Byte1 DS XL1 Flag1 EQU X'80' Flag2 EQU X'40' Flag3 EQU X'20' Flag4 EQU X'10' Flag5 EQU X'08' Flag6 EQU X'04' Flag7 EQU X'02' Flag8 EQU X'01' Byte1 DS CL1 HW1 DS H Now, are you going to tell me that I cannot do what I just did? I am looking at some working code right now that allows me to flip the bits on the first byte, store a character in the second, and store a halfword
binary in the next two. How is it I can do that?

I'm puzzled why you think that would be a problem. The fact that the
byte is part of a fullword does not make it any less a byte in its own
right.

DS

[Keith R. Williams]

In article <blq3og$one$1@nntp.webmaster.com>,
davids@webmaster.com says... "David Schwartz" <davids@webmaster.com> wrote in message news:blq3l9$ol7$1@nntp.webmaster.com... So there's no such thing as a bit that's not part of a fullword. The point is that if you're using a high-level language, bit operations may be converted into integer operations and vice-versa. The compiler will choose the more efficient form.

Only if the compiler can decipher your meaning. It's up to you
to make your data structures clear. I think that was Deano's
point. There *are* elements called "bits" and there are
constructs to manipulate such "bits". Many applications like
wider operand widths.
So you really don't know (unless you look at the assembler output, which can vary based on optimization settings and so on) whether you're doing bit operations or integer operations.

Yawn. Stating the obvious isn't really that interesting.

--
Keith

[Dean Kent]

"David Schwartz" <davids@webmaster.com> wrote in message
news:blq8fr$rfp$1@nntp.webmaster.com... I'm puzzled why you think that would be a problem. The fact that the byte is part of a fullword does not make it any less a byte in its own right.

It is also part of a halfword, and a quadword - so I'm puzzled why you are
stating 'facts' that have absolutely nothing to do with the original point.
Let me refresh your mind what that was:
Dean: I don't get the 32 variables comment. Are you implying that the
only wayto reference a bit is if it is part of a fullword?
David Schwartz: Since a bit always is part of a fullword, your question
doesn't reallymake sense.

Now, I just showed that I can reference a bit in a single byte without
requiring 32 single bit 'variables'. A 'fullword' is simply an alignment,
just as is byte, halfword, doubleword and quadword. Exactly what the
alignment has to do with using an individual bit within a byte is beyond me,
so if you can make an actual point rather than just state 'facts' that have
no bearing on the issue, it might be more useful. Or is this simply a way
to start an argument from nothing?

Regards,
Dean


DS

[David Schwartz]

"Dean Kent" <dkent@realworldtech.com> wrote in message
news:gY2gb.11962$us4.8175@newssvr25.news.prodigy.com...
"David Schwartz" <davids@webmaster.com> wrote in message news:blq8fr$rfp$1@nntp.webmaster.com...
I'm puzzled why you think that would be a problem. The fact that the byte is part of a fullword does not make it any less a byte in its own right.
It is also part of a halfword, and a quadword - so I'm puzzled why you are stating 'facts' that have absolutely nothing to do with the original
point. Let me refresh your mind what that was:
Dean: I don't get the 32 variables comment. Are you implying that theonly wayto reference a bit is if it is part of a fullword?
David Schwartz: Since a bit always is part of a fullword, your questiondoesn't reallymake sense.
Now, I just showed that I can reference a bit in a single byte without requiring 32 single bit 'variables'.

Yes, you can reference a bit in a single byte. I'm not sure what you
mean by 'requiring' 32 single bit variables. To assembly language and the
processor, there's no difference between 32 single bit variables (assuming
they're qword aligned) and an integer quadword. Any single bit operation
(set this bit) has an equivalent integer operation (or with this constant).
A 'fullword' is simply an alignment, just as is byte, halfword, doubleword and quadword. Exactly what the alignment has to do with using an individual bit within a byte is beyond
me, so if you can make an actual point rather than just state 'facts' that
have no bearing on the issue, it might be more useful. Or is this simply a
way to start an argument from nothing?

I'm not the one starting an argument. If I state facts that have no
bearing on the issue, no argument should be started. Assuming arguendo that
what I'm saying is both true and irrelevant, it should not start an
argument, it should simply dead end. The fact that it has started an
argument proves that either someone things it's not true or someone thinks
it's relevant. So your claim that it's both obviously true and irrelevant
(if that's your claim, it's hard to tell) is clearly false.

There is no distinction between 'just a bit' and 'a bit that is part of
a quadword'. Every bit is part of a quadword if you want to think of it that
way. You are free to use bit operations or integer operations, and if you
work in a high-level language, you may not even get the one you asked for
(not that you should care). There are cases (like memory-mapped I/O access
or SMP issues) where it may make a difference whether you get bit accesses
or larger width accesses, and then high-level languages can get you into
trouble if you aren't careful.

DS

[Dean Kent]

"David Schwartz" <davids@webmaster.com> wrote in message
news:blqomk$5di$1@nntp.webmaster.com... Yes, you can reference a bit in a single byte. I'm not sure what you mean by 'requiring' 32 single bit variables.

Simply look at the post I was originally responding to. The comment was
made that boolean operations are rarely done because it is difficult to
justify 32 boolean variables. I was confused why this would be an issue,
since bit manipulation can be done on a single byte...
To assembly language and the processor, there's no difference between 32 single bit variables (assuming they're qword aligned) and an integer quadword.

Uh, you mean a fullword? Four bytes contain 32 bits, each of which can be
assigned a unique label - resulting in 32 single bit variables (yes or no
flags, essentially). Are we talking about the same thing here?
Any single bit operation (set this bit) has an equivalent integer operation (or with this
constant).

In order to twiddle a bit, one must reference the byte itself. Big deal, so
what. What has this to do with whether a bit is always part of a fullword
or not?
I'm not the one starting an argument.

Actually, you were. It was your assertion that 'every bit is part of a
fullword' and that my question 'made no sense'.
If I state facts that have no bearing on the issue, no argument should be started. Assuming arguendo that what I'm saying is both true and irrelevant, it should not start an argument, it should simply dead end.

No, because you first started the argument, and then began to use irrelevant
facts to bolster it.
The fact that it has started an argument proves that either someone things it's not true or someone thinks it's relevant. So your claim that it's both obviously true and irrelevant (if that's your claim, it's hard to tell) is clearly false.

The argument was started by claiming that my question made no sense by
making a false statement. You then threw out a series of irrelevant facts
to 'prove' whatever it was you were trying to prove. Therefore, your
reasoning above is clearly a load of hogwash.

There are two possible definitions of a fullword that I am aware of:

1) An alignment in memory, which refers only to a memory address divisible
by 4 (in most architectures) - and has nothing to do with the following
three bytes.
2) A data definition within a program that is one word in length, and that
is aligned at a fullword address (in most current architectures).

Consider the following:

ByteDef DS CL1
FW1 DS F

ByteDef is a byte. There is no guarantee that it will actually reside on a
fullword boundary. However, FW1 *will* reside on a fullword boundary.
Let us assume that ByteDef is at address 1001. The implied length of
ByteDef is 1 - which means that it cannot be a fullword data element. If
you were to reference the byte at address 1000, it would not have a length
value of 4. In fact, it would have no implied length at all, so you would
have to supply one. If you supplied a length value of 4 to ByteDef, it
would not be a fullword because it would not be aligned properly. It would,
in fact, be 4 bytes that crossed a fullword boundary.
There is no distinction between 'just a bit' and 'a bit that is part
of a quadword'.

I get the feeling that we are coming from a completely different viewpoint
here. When you say 'there is no distinction', are you talking about from
the memory controller's point of view, the programmer's point of view or
something else? You might be talking about how data is fetched into a
cacheline, but that has absolutely nothing to do with how data is referenced
by the program or the CPU. A bit may be associated with a single byte, a
halfword, a fullword, a doubleword or a quadword - but that is *program*
dependent. The CPU has no care whether the byte being referenced has any
relationship to the one before or after it. It only knows that it operates
on data at some address for some particular length. Is this not correct?
Every bit is part of a quadword if you want to think of it that way.

Why would I want to think of it that way? What has this to do with 'every
bit is part of a fullword', except as an extension of that concept - which I
still don't agree with...
You are free to use bit operations or integer operations, and if you work in a high-level language, you may not even get the one you asked for (not that you should care). There are cases (like memory-mapped I/O access or SMP issues) where it may make a difference whether you get bit accesses or larger width accesses, and then high-level languages can get you into trouble if you aren't careful.

I have no clue what you are trying to present here. I can do anything I
want, whenever I want - but that doesn't mean I will get the expected
results. What exactly is it you are trying to show?

Regards,
Dean
DS

[George Macdonald]

On Sun, 05 Oct 2003 15:38:51 GMT, Tony Hill <hilla_nospam_20@yahoo.ca>
wrote:
On Sat, 04 Oct 2003 04:59:30 GMT, "Dean Kent"<dkent@realworldtech.com> wrote:"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in messagenews:9444831a0d4d28ba6750fa7c39df1891@news.1usenet.com... Bit operations are generally VERY rare breeds in this day and age, mainly because they don't really offer you anything over integer operations. The chance of having more than 32 boolean variables in a single application and being used in a relatively short period of time (such that they aren't been pushed out of renamed registers or at the very least the L1 cache) is pretty darn slim if you ask me. The only case where I've seen use of a lots of boolean stuff and shifting is in cryptography, and that's an area that has already been discussed as benefiting strongly from 64-bit processing.Gosh, we use them quite a bit where I work... but then, we are also a veryrare breed these days.That's an understatement! Ohh, err.. yeah mean about the programmingthing :>I don't get the 32 variables comment. Are you implying that the only way toreference a bit is if it is part of a fullword?I was trying to understand how going from 32-bit to 64-bit registerswould somehow improve performance of boolean operations. The onlything I can see, off the top of my head, is if you have an array ofbooleans that is more than 32-bits in length, ie not just a couple ofboolean values here and there.

Well that's it precisely - say you have a bit map reflecting the status of
100s of thousands of items, if you have to go through the whole thing on,
e.g. a masking operation... Maybe not something that's done by everybody
every day but it is done.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

[Judd]

"Keith R. Williams" <krw@attglobal.net> wrote in message
news:MPG.19e73d0351c2d42d98a751@enews.newsguy.com... In article <Xnmeb.404$W7.41074@news.uswest.net>, IhateSpam@stopspam.com says... You haven't a clue, eh kid? DeanK has documented some of his inanities. You might wish to search the archives of this group before showing your green side. Are you Mulder or Scully? No (I guess you can't read either), but I've been around the Tom block a few times. His site is a waste of bits.

My you're getting frustrated.
I've seen him give some interesting conclusions on his benchmarks that I would not have come to based on the figures,
but that's about it. "Interesting" is one way you could put it. It's not exactly the word I'd use, at least without quotes.

We're waiting with bated breath to hear the words you would use.
Of course, I'm clueless and green. LMAO! Apparently you are.

If I don't agree with your insipid claims, then I'm clueless. OK! Keith,
save your breath... just don't go home and beat your wife already. It's
just an internet forum. No need to get so frustrated.
Some of you guys are crackups. Look in the mirror.

Dumb! Save the lame responses and take a cold shower already.

[David Schwartz]

"Dean Kent" <dkent@realworldtech.com> wrote in message
news:Ey6gb.12018$Z87.9896@newssvr25.news.prodigy.com...
"David Schwartz" <davids@webmaster.com> wrote in message news:blqomk$5di$1@nntp.webmaster.com...
To assembly language and the processor, there's no difference between 32 single bit variables
(assuming they're qword aligned) and an integer quadword.
Uh, you mean a fullword? Four bytes contain 32 bits, each of which can
be assigned a unique label - resulting in 32 single bit variables (yes or no flags, essentially). Are we talking about the same thing here?

I think so.
Any single bit operation (set this bit) has an equivalent integer operation (or with this constant).
In order to twiddle a bit, one must reference the byte itself. Big deal,
so what. What has this to do with whether a bit is always part of a
fullword or not?

Depending upon precisely what you mean by 'reference', what you're
saying may not be precisely true. For example, suppose I have a bit stored
inside the byte at address 1. I can clear that bit by performing an integer
operation on the 32-bit value stored at address zero (though, of course,
it's really stored at addresses zero through three inclusive). So you can
twiddle a bit without addressing the byte it contains (except through the
32-bits that contain it).
I'm not the one starting an argument.
Actually, you were. It was your assertion that 'every bit is part of a fullword' and that my question 'made no sense'.

Exactly. Every bit is part of a byte. Every byte is part of a 32-bit
chunk. There is no such thing as 'a bit that's not part of a 32-bit unit'.
All bits are, whether you choose to address them that way or not.
If I state facts that have no bearing on the issue, no argument should be started. Assuming arguendo that what I'm saying is both true and irrelevant, it should not start an argument, it should simply dead end.
No, because you first started the argument, and then began to use
irrelevant facts to bolster it.

So do you still maintain that you can have a bit that's not part of a
32-bit quantity? How about a bit that's not part of a byte? A byte that's
not part of a page?
There are two possible definitions of a fullword that I am aware of:
1) An alignment in memory, which refers only to a memory address divisible by 4 (in most architectures) - and has nothing to do with the following three bytes. 2) A data definition within a program that is one word in length, and that is aligned at a fullword address (in most current architectures).

Neither of these definitions is the common definition of 'fullword'. A
'fullword' is a 4-byte quantity aligned at a 4-byte boundary. A common usage
would be, for example, "on x86 Linux, pointers are usually fullwords". This
means both that they're 32-bit quantities and that they're 32-bit aligned.
If I was talking about a quantity that had 4-byte alignment but didn't refer
to the following bytes, I'd refer to "fullword alignment".
There is no distinction between 'just a bit' and 'a bit that is part of a quadword'.
I get the feeling that we are coming from a completely different viewpoint here. When you say 'there is no distinction', are you talking about from the memory controller's point of view, the programmer's point of view or something else? You might be talking about how data is fetched into a cacheline, but that has absolutely nothing to do with how data is
referenced by the program or the CPU. A bit may be associated with a single byte, a halfword, a fullword, a doubleword or a quadword - but that is *program* dependent. The CPU has no care whether the byte being referenced has
any relationship to the one before or after it. It only knows that it
operates on data at some address for some particular length. Is this not correct?

I'm talking about from any point of view. The LSB of byte 3 is also a
middle bit in the fullword from address zero through address four. Every bit
is part of a byte. Every byte is part of a word. Every word is part of a
fullword. Every fullword is part of a quadword. Every quadword is part of a
page.
Every bit is part of a quadword if you want to think of it that way.
Why would I want to think of it that way? What has this to do with
'every bit is part of a fullword', except as an extension of that concept - which
I still don't agree with...

The point is, whether or not you choose to think of it that way doesn't
change what it is.
You are free to use bit operations or integer operations, and if you work in a high-level language, you may not even get the one you asked
for (not that you should care). There are cases (like memory-mapped I/O
access or SMP issues) where it may make a difference whether you get bit
accesses or larger width accesses, and then high-level languages can get you into trouble if you aren't careful.
I have no clue what you are trying to present here. I can do anything I want, whenever I want - but that doesn't mean I will get the expected results. What exactly is it you are trying to show?

I think you've descended into being deliberately dense. I can't imagine
how you could possibly misunderstand the below:
Really. How come I can define a byte and reference the individual bits within it? I guess my assembler just isn't as smart as you... :-).
Believe it or not, there are three other bytes next to that one, the set of which can be called a 'fullword'. ;)
Are you absolutely certain? Are you claiming that I can only define abyte in my program that is aligned on a fullword?

How much clearer can I be -- there are always 3 bytes next to any
particular byte which together form a fullword, that is, a 32-bit quantity
aligned on a 32-bit boundary.

DS

[Keith R. Williams]

In article <brjgb.180$gG3.26838@news.uswest.net>,
IhateSpam@stopspam.com says... "Keith R. Williams" <krw@attglobal.net> wrote in message news:MPG.19e73d0351c2d42d98a751@enews.newsguy.com... In article <Xnmeb.404$W7.41074@news.uswest.net>, IhateSpam@stopspam.com says... > > You haven't a clue, eh kid? DeanK has documented some of his > inanities. You might wish to search the archives of this group > before showing your green side. > Are you Mulder or Scully? No (I guess you can't read either), but I've been around the Tom block a few times. His site is a waste of bits. My you're getting frustrated.

Oh no! You're simply silly.

<snip useless garbage>
Look in the mirror. Dumb! Save the lame responses and take a cold shower already.

No, I'm serious. You really need to look in the mirror.

--
Keith

[Dean Kent]

"David Schwartz" <davids@webmaster.com> wrote in message
news:blshma$6c6$1@nntp.webmaster.com... Depending upon precisely what you mean by 'reference', what you're saying may not be precisely true. For example, suppose I have a bit stored inside the byte at address 1. I can clear that bit by performing an
integer operation on the 32-bit value stored at address zero (though, of course, it's really stored at addresses zero through three inclusive). So you can twiddle a bit without addressing the byte it contains (except through the 32-bits that contain it).

You know, I started to answer point-by-point, but I realize that you have
only one point - and it is incorrect. The fact that memory addresses have
alignments does not in any way imply that there is any relationship with
storage locations between these alignments. The fact that a byte resides
on a fullword boundary does not mean it has any relationship with the three
bytes after it. Any relationship is defined by the program. A 32-bit
value is not necessarily a fullword - even if the first byte resides on a
fullword boundary. Consider the following:


DS 0F
HW1 DS H
VAR1 DS XL4

How will that actually be stored in memory? HW1 will be aligned on a
fullword boundary, and VAR1 will be on a halfword boundary. I could *not*
reference VAR1 as a fullword. I *could* reference HW1 as a fullword by
overriding its implicit length - but doing so would make absolutely no sense
at all. The bytes in VAR1 are not part of any fullword, and it would be
foolish to claim that it is.

This whole discussion sounds just like the thread about Hertz and
bandwidth - you are trying to define something based upon your own erroneous
concept of how memory is organized. I maintain that if I define a byte,
there is absolutely no relationship to any other byte except as I define it.
Memory is defined by the process that uses it, and that is all. This
includes bytes, halfwords, words, double words, pages or any other unit you
want to mention. Memory is simply a contiguous set of addresses, and the
alignment is only a convenience for certain processes for the purpose of
calculating addresses and validating the data contained therein.

I don't think this is worth discussing any further. You can continue to
hold on to your misconceptions if you wish, but don't expect me to buy into
it. :-).

Regards,
Dean

[David Schwartz]

"Dean Kent" <dkent@realworldtech.com> wrote in message
news:XGqgb.12204$lK2.7583@newssvr25.news.prodigy.com...
You know, I started to answer point-by-point, but I realize that you have only one point - and it is incorrect. The fact that memory addresses
have alignments does not in any way imply that there is any relationship with storage locations between these alignments.

Umm, huh? Yes, they do have a relationship, namely that all of those
addresses can be collectively referred to as a 'page' or a 'byte' or a
'fullword' or whatever. Two bits in a byte have a relationship, they share a
byte, even if you can/do address them as individual bits.
The fact that a byte resides on a fullword boundary does not mean it has any relationship with the
three bytes after it.

Yes, it does, it means those four bytes form a fullword. Whereas that
byte and the three before it do not.
Any relationship is defined by the program.

Really? So the program can define bytes 1, 2, 3, and 4 as a fullword if
it wants to? Or bytes 3, 7, 9, and 12?
A 32-bit value is not necessarily a fullword - even if the first byte resides on a fullword boundary.

A 32-bit value aligned on a fullword boundary is a fullword, by
definition.
Consider the following: DS 0F HW1 DS H VAR1 DS XL4 How will that actually be stored in memory? HW1 will be aligned on a fullword boundary, and VAR1 will be on a halfword boundary. I could
*not* reference VAR1 as a fullword. I *could* reference HW1 as a fullword by overriding its implicit length - but doing so would make absolutely no
sense at all. The bytes in VAR1 are not part of any fullword, and it would be foolish to claim that it is.

So you're saying it's impossible to address the bytes in VAR1 as part of
a fullword? What would stop code from anding the address of VAR1 with
0xfffffffc and storing to that address as a 32-bit quantity?
This whole discussion sounds just like the thread about Hertz and bandwidth - you are trying to define something based upon your own
erroneous concept of how memory is organized. I maintain that if I define a byte, there is absolutely no relationship to any other byte except as I define
it.

No, this is totally false. If this were so, then you should be able to
define any relationship you chose. If it was totally up to you which bytes
made up a fullword, you should be able to chose to make bytes 1, 3, 7, and
41 a fullword if you wanted to. But the fact is, only certain bytes can be
made into fullwords, and that's because those bytes already have a certain
relationship to each other -- namely they're consecutive and aligned on a
fullword boundary.
Memory is defined by the process that uses it, and that is all.

So why can't the process define bytes 1, 3, 43, and 1,002 as a fullword
and use them that way?
This includes bytes, halfwords, words, double words, pages or any other unit
you want to mention. Memory is simply a contiguous set of addresses, and
the alignment is only a convenience for certain processes for the purpose of calculating addresses and validating the data contained therein.

Would you even say this was so on a processor that was only capable of
32-bit accesses to aligned fullwords?
I don't think this is worth discussing any further. You can continue to hold on to your misconceptions if you wish, but don't expect me to buy
into it. :-).

I think you're just very used to working on processors that are capable
of variable-sized accesses and out-of-alignment accesses and you're letting
this color your use of standard terms into a non-standard form.

Byte 2 is part of the fullword at address 0, no matter what the program
wants to do.

DS

[Dean Kent]

"David Schwartz" <davids@webmaster.com> wrote in message
news:bltj5b$pju$1@nntp.webmaster.com... Umm, huh? Yes, they do have a relationship, namely that all of those addresses can be collectively referred to as a 'page' or a 'byte' or a 'fullword' or whatever. Two bits in a byte have a relationship, they share
a byte, even if you can/do address them as individual bits.

No. The fact that you can *define* them as such in no way means that these
relationships exist at any other time than when they are defined. A byte
has an implied alignment and length, so does a halfword, a fullword, etc.
They only have these attributes when they are *defined*. Again, consider:

DS 0F
HW1 DS H
HW2 DS H

Neither HW1 nor HW2 is a fullword. You cannot use either one as a
fullword. You cannot reference the four bytes they use as a fullword....
*UNLESS* you put a label on the first definition such as

FW1 DS 0F
HW1 DS H
HW2 DS H

Now, you can use the bytes as a fullword because you have *defined it* as
such. There is no implied fullword without it. Period.
The fact that a byte resides on a fullword boundary does not mean it has any relationship with the three bytes after it. Yes, it does, it means those four bytes form a fullword. Whereas that byte and the three before it do not.

NO. A fullword exists only when it is defined as such.
Any relationship is defined by the program. Really? So the program can define bytes 1, 2, 3, and 4 as a fullword
if it wants to? Or bytes 3, 7, 9, and 12?

I didn't say that.

DS XL4
is not a fullword, because while it has a length of 4, it has byte
alignment.

DS F
*IS* a fullword, because it has both a length *and* a word alignment

This is true even if they occupy the exact same memory locations.
A 32-bit value is not necessarily a fullword - even if the first byte resides on
a fullword boundary. A 32-bit value aligned on a fullword boundary is a fullword, by definition.

No, it must be defined as such. It might *happen* to reside on a fullword
boundary - but if you don't define it as such, then it has no implied word
alignment, and therefore is not a fullword. The key is is that a fullword
has an *implied* length of 4 and an *implied* word alignment. An XL4
definition has an implied byte alignment, therefore it is *not* a fullword,
even if it is on a fullword boundary.
Consider the following: DS 0F HW1 DS H VAR1 DS XL4 How will that actually be stored in memory? HW1 will be aligned on a fullword boundary, and VAR1 will be on a halfword boundary. I could *not* reference VAR1 as a fullword. I *could* reference HW1 as a fullword by overriding its implicit length - but doing so would make absolutely no sense at all. The bytes in VAR1 are not part of any fullword, and it would
be foolish to claim that it is. So you're saying it's impossible to address the bytes in VAR1 as part
of a fullword? What would stop code from anding the address of VAR1 with 0xfffffffc and storing to that address as a 32-bit quantity?

You still aren't working with a 'fullword'. You are working with a string
of bytes. You *can* reference it as a fullword *if* you redefine it as
one:

DS 0F
HW1 DS H
VAR1 DS 0XL4
HW2 DS H
FW1 DS F

Now, you can refer to FW1 as a fullword (it has an implied alignment), but
not VAR1 (it has a byte alignment)
This whole discussion sounds just like the thread about Hertz and bandwidth - you are trying to define something based upon your own erroneous concept of how memory is organized. I maintain that if I define a
byte, there is absolutely no relationship to any other byte except as I define it. No, this is totally false. If this were so, then you should be able to define any relationship you chose. If it was totally up to you which bytes made up a fullword, you should be able to chose to make bytes 1, 3, 7, and 41 a fullword if you wanted to. But the fact is, only certain bytes can be made into fullwords, and that's because those bytes already have a certain relationship to each other -- namely they're consecutive and aligned on a fullword boundary.

You are being extremely obtuse. I didn't say you could define alignment
however you want. I am talking about defining the data type, and the
assembler/compiler will decide where that variable goes. If you use high
level languages, all of these definitions are done *for* you, so you don't
even have the opportunity to screw them up. In assembler if you define
these two variables:

VAR1 DS X
VAR2 DS F

It might look like any of these things in storage:

Address Example 1 Example 2 Example 3 Example 4
--------- ----------- ---------- ----------- ----------
1000 VAR1 undef undef undef
1001 undef VAR1 undef undef
1002 undef undef VAR1 undef
1003 undef undef undef VAR1
1004 VAR2 VAR2 VAR2 VAR2
1005 VAR2 VAR2 VAR2 VAR2
1006 VAR2 VAR2 VAR2 VAR2
1007 VAR2 VAR2 VAR2 VAR2

What determines where the actual storage is depends upon what was defined
*prior* to these definitions. There is *no* fullword starting at address
1000. I cannot use any label that has an implied length of 4 at that
address. Period. It hasn't been defined, and therefore it doesn't exist as
such. I *can* reference those byte locations, and I can even force a
length - but that is an explicit definition, and I have no implicit word
alighment - so it still isn't a fullword, even if I am referencing address
1000. Fact is, it is likely I don't really know what the address is until
*after* I compile it, so trying to use it as a fullword without defining it
as such is asking for trouble...
Memory is defined by the process that uses it, and that is all. So why can't the process define bytes 1, 3, 43, and 1,002 as a
fullword and use them that way?

Because, as you have said yourself - a fullword has the characteristics of
being both 4 bytes in length *and* on a fullword boundary. These are
*implied* characteristics, which are determined by what you define in your
program. Period. I can define the same area of storage in many ways:

Fullword
Two halfwords
four bytes

Only the first is a fullword. The others lack either the length or the
alignment characteristic, or both.
This includes bytes, halfwords, words, double words, pages or any other unit you want to mention. Memory is simply a contiguous set of addresses, and the alignment is only a convenience for certain processes for the purpose of calculating addresses and validating the data contained therein. Would you even say this was so on a processor that was only capable of 32-bit accesses to aligned fullwords? I don't think this is worth discussing any further. You can continue
to hold on to your misconceptions if you wish, but don't expect me to buy into it. :-). I think you're just very used to working on processors that are
capable of variable-sized accesses and out-of-alignment accesses and you're
letting this color your use of standard terms into a non-standard form.

Ha! Since the system I work on has been around much longer than any x86
processor, I would say that my terms are 'standard'.
Byte 2 is part of the fullword at address 0, no matter what the
program wants to do.

No. There is no fullword starting at address 0 if it has not been defined
to be a fullword. It is just a byte in storage. Period. Pages are
defined by a process, and have no meaning outside of that process.
Cachelines are defined by a process, and have no meaning outside of that
process. The same goes for any other grouping of memory. Consider a
fullword to be something like a structure in your program - you can use the
storage in that structure any way you want, but if you want it to be a
*structure* you have to define it as such.

If this is too difficult for you, I suggest you stick with higher level
languages, as assembly will simply confuse you...

Regards,
Dean DS

[David Schwartz]

"Dean Kent" <dkent@realworldtech.com> wrote in message
news:Hhtgb.12268$O55.7257@newssvr25.news.prodigy.com...
"David Schwartz" <davids@webmaster.com> wrote in message news:bltj5b$pju$1@nntp.webmaster.com...
Umm, huh? Yes, they do have a relationship, namely that all of those addresses can be collectively referred to as a 'page' or a 'byte' or a 'fullword' or whatever. Two bits in a byte have a relationship, they
share a byte, even if you can/do address them as individual bits.
No. The fact that you can *define* them as such in no way means that
these relationships exist at any other time than when they are defined.

If the relationship didn't exist until it was defined, then I should be
able to define any relationship I want, say calling bytes 1, 8, 13, and 43 a
fullword. The fact that I can call bytes 0-3 a fullword and not bytes 1-4
proves that 0-3 have some relationship already that 1-4 do not.
A byte has an implied alignment and length, so does a halfword, a fullword, etc. They only have these attributes when they are *defined*. Again, consider:

Not at all. A hypothetical CPU might, for example, map all byte accesses
to fullword accesses invisibly to the programmer (except for SMP
considerations and so on).
DS 0F HW1 DS H HW2 DS H Neither HW1 nor HW2 is a fullword. You cannot use either one as a fullword. You cannot reference the four bytes they use as a fullword.... *UNLESS* you put a label on the first definition such as FW1 DS 0F HW1 DS H HW2 DS H Now, you can use the bytes as a fullword because you have *defined it* as such. There is no implied fullword without it. Period.

Not true. You can use them as a fullword simply by ANDing the address.
The processor might address them as fullwords internally. Suppose, for
example, that the cache always loads fullwords. Your byte operations will
always map perfectly to fullword cache operations, proving that certain sets
of bytes have certain relationships regardless of how the programmer chooses
to view them.
The fact that a byte resides on a fullword boundary does not mean it has any relationship with the three bytes after it.
Yes, it does, it means those four bytes form a fullword. Whereas
that byte and the three before it do not.
NO. A fullword exists only when it is defined as such.

A fullword is defined as four adjacent bytes aligned on a 4-byte
boundary. It's *always* defined as such. Bytes 0, 1, 2, and 3 always form a
fullword and bytes 1, 2, 3, and 4 never do.
Any relationship is defined by the program.
Really? So the program can define bytes 1, 2, 3, and 4 as a fullword if it wants to? Or bytes 3, 7, 9, and 12?
I didn't say that. DS XL4 is not a fullword, because while it has a length of 4, it has byte alignment.

Ahh, so some bytes can never be a fullword, regardless of what the
programmer wants to do. Hmm, now why would that be?
DS F *IS* a fullword, because it has both a length *and* a word alignment This is true even if they occupy the exact same memory locations.

No. "DS F" insists upon a fullword. 'DS XL4' requests 4 bytes that may
or may not form a fullword.

Consider, for example, the following statement from a VAX manual, "On
some systems, C aligns long word data items to fullword boundaries. On such
systems, a C structure may require an integral number of fullwords, even if
the actual data do not occupy all of the last fullword."

What are we to make of this? How can a C structure even contain an
integral number of fullword if the actual data is not defined to occupy all
of the last fullword?

IBM defines a fullword as "4 bytes that start at an address evenly
divisible by 4". Notice that it says nothing about how the program chooses
to interpret them, simply that it must be 4 bytes and that it must start at
an address divisible by 4.
A 32-bit value is not necessarily a fullword - even if the first byte resides
on a fullword boundary.
A 32-bit value aligned on a fullword boundary is a fullword, by definition.
No, it must be defined as such.

A fullword already is defined a such. A fullword is a 32-bit quantity
aligned on a 4-byte boundary, full stop.
It might *happen* to reside on a fullword boundary - but if you don't define it as such, then it has no implied word alignment, and therefore is not a fullword. The key is is that a
fullword has an *implied* length of 4 and an *implied* word alignment. An XL4 definition has an implied byte alignment, therefore it is *not* a
fullword, even if it is on a fullword boundary.

An XL4 need not be a fullword. An XL4 can be a fullword. An XL4 can be a
32-bit quantity aligned ona 4-yte boundary, and that is a fullword by
definition. You can specifically ask for a fullword, but you may get one
even if you don't ask for it.

Wouldn't it be crazy to say that a bit is not part of a byte just
because I declared it as a bit variable in the C language?
No, this is totally false. If this were so, then you should be able
to define any relationship you chose. If it was totally up to you which
bytes made up a fullword, you should be able to chose to make bytes 1, 3, 7,
and 41 a fullword if you wanted to. But the fact is, only certain bytes can
be made into fullwords, and that's because those bytes already have a
certain relationship to each other -- namely they're consecutive and aligned on
a fullword boundary.
You are being extremely obtuse. I didn't say you could define alignment however you want. I am talking about defining the data type, and the assembler/compiler will decide where that variable goes. If you use high level languages, all of these definitions are done *for* you, so you don't even have the opportunity to screw them up. In assembler if you define these two variables: VAR1 DS X VAR2 DS F It might look like any of these things in storage: Address Example 1 Example 2 Example 3 Example 4 --------- ----------- ---------- ----------- ---------- 1000 VAR1 undef undef undef 1001 undef VAR1 undef undef 1002 undef undef VAR1 undef 1003 undef undef undef VAR1 1004 VAR2 VAR2 VAR2 VAR2 1005 VAR2 VAR2 VAR2 VAR2 1006 VAR2 VAR2 VAR2 VAR2 1007 VAR2 VAR2 VAR2 VAR2 What determines where the actual storage is depends upon what was defined *prior* to these definitions.

All of this is true but utterly irrelevant.
There is *no* fullword starting at address 1000.

Right. And bytes 0 through 3 always form a fullword. Why? Because
they're 4 consecutive bytes starting at an address divisible by 4, and that
is the exact definition of a fullword.
I cannot use any label that has an implied length of 4 at that address. Period. It hasn't been defined, and therefore it doesn't exist
as such. I *can* reference those byte locations, and I can even force a length - but that is an explicit definition, and I have no implicit word alighment - so it still isn't a fullword, even if I am referencing address 1000. Fact is, it is likely I don't really know what the address is until *after* I compile it, so trying to use it as a fullword without defining
it as such is asking for trouble...

Right, because it might or might not actually *be* a fullword. You
haven't demanded a fullword, so you might or might not get it.

If somebody asks you, "do the bytes at addresses 1024, 1025, 1026, and
1026 form a fullword?" would you reply, "they might or might not depending
upon how you declared them"? If so, I submit that you are the only person
who uses this term this way and you are in disagreement with every
definition I have found.
So why can't the process define bytes 1, 3, 43, and 1,002 as a fullword and use them that way?
Because, as you have said yourself - a fullword has the characteristics of being both 4 bytes in length *and* on a fullword boundary. These are *implied* characteristics, which are determined by what you define in your program. Period. I can define the same area of storage in many ways:

Exactly. That's what makes a fullword, If it has those characteristics,
it is a fullword, regardless of how you choose to refer to it. For example:

bool IsAFullWord(void *ptr, int len)
{
if(len!=4) return false;
uintptr_t p=(uintptr_t) ptr;
return (p&3)==0;
}

Please take this C code to anyone you consider a competent expert and,
without biasing them with your silliness, ask them if this code will
correctly determine whether the pointer and length form a fullword.
Fullword Two halfwords four bytes
Only the first is a fullword. The others lack either the length or the alignment characteristic, or both.

Well, they might lack the alignment characteristic, they might not. For
example, I've seen code that checks for alignment, and if so addresses as a
fullword, and if not addresses by bytes.
Would you even say this was so on a processor that was only capable
of 32-bit accesses to aligned fullwords?
Ha! Since the system I work on has been around much longer than any x86 processor, I would say that my terms are 'standard'.

So if you had a system that could only access fullwords, but would let
you define bytes and halfwords and all sorts of other things (however, it
always mapped them to fullword operations), would you still say you only
have a fullword if you ask for one specifically?
Byte 2 is part of the fullword at address 0, no matter what the program wants to do.
No. There is no fullword starting at address 0 if it has not been defined to be a fullword. It is just a byte in storage. Period. Pages are defined by a process, and have no meaning outside of that process. Cachelines are defined by a process, and have no meaning outside of that process. The same goes for any other grouping of memory. Consider a fullword to be something like a structure in your program - you can use
the storage in that structure any way you want, but if you want it to be a *structure* you have to define it as such.

A fullword is a 32-bit quantity aligned at a byte address that is
divisible by 4. No more, no less. It is a fullword even if there is no
program to address it. Even if there exist no computers to process them.
If this is too difficult for you, I suggest you stick with higher level languages, as assembly will simply confuse you...

I suggest you use terms the same way everyone else does. Can you find
anything even close to official to cite your rather bizarre interpretation
of what a fullword is? I can cite dozens of places that define a fullword
the way everyone I've ever met has used it.

DS

[David Schwartz]

I know how to tell which of us is correct. Let's pose the following
multiple choice question:

If VAR1 is declared:
VAR1 DS XL4
which of the following is true:

A) VAR1 is always a fullword
B) VAR1 is never a fullword
C) VAR1 might be a fullword but it is not guaranteed

Now, you would maintain the answer is B, I maintain that it is C. So why
don't you and I each ask this question to several people whose opinions we
know and respect. We'll see what answers we get.

DS

[Dean Kent]

"David Schwartz" <davids@webmaster.com> wrote in message
news:bltsts$v6o$1@nntp.webmaster.com... I know how to tell which of us is correct. Let's pose the following multiple choice question: If VAR1 is declared: VAR1 DS XL4 which of the following is true: A) VAR1 is always a fullword B) VAR1 is never a fullword C) VAR1 might be a fullword but it is not guaranteed Now, you would maintain the answer is B, I maintain that it is C. So
why don't you and I each ask this question to several people whose opinions we know and respect. We'll see what answers we get.

This is not the original dispute. Whether someone will claim that a random
4 bytes on a fullword boundary is or is not a fullword is not my concern.
What you said is that the bytes in VAR1 are part of at least one fullword,
and possibly two fullwords - whether it is defined that way or not.

Here is a quote (again) from the z/OS Principles of Operations:

"Certain units of information must be on an integral boundary in storage. A
boundary is called integral for a unit of information when its storage
address is a multiple of the length of the unit in bytes. Special names are
given to fields of 2, 4, 8, and 16 bytes on an integral boundary. A halfword
is a group of two consecutive bytes on a two-byte boundary and is the basic
building block of instructions. A word is a group of four consecutive bytes
on a four-byte boundary."

Note the use of the word "field", which means a defined set of data.

Now, the claim I am disputing is that if I define a byte "DS XL1", it *is*
part of a fullword. It isn't because the three bytes adjacent to it are
not part of the same *FIELD*.

Regards,
Dean
DS

[Dean Kent]

"David Schwartz" <davids@webmaster.com> wrote in message
news:bltsgp$v4g$1@nntp.webmaster.com... If the relationship didn't exist until it was defined, then I should
be able to define any relationship I want, say calling bytes 1, 8, 13, and 43
a fullword. The fact that I can call bytes 0-3 a fullword and not bytes 1-4 proves that 0-3 have some relationship already that 1-4 do not.

NO no no no. The relationship is with the preceding or following bytes -
not randomly distributed. Defining a relationship is called a 'field'. A
single byte is a field. Two consecutive bytes defined are a field. Four
consecutive bytes defined are a field. I never said you could define a
random relationship, just that there is no *inherent* relationship between
bytes in memory.
Not at all. A hypothetical CPU might, for example, map all byte
accesses to fullword accesses invisibly to the programmer (except for SMP considerations and so on).

Nonsense. This would either prevent data operands from being shorter than
a fullword, or would force extreme waste of memory. Nonsense, I say.
Not true. You can use them as a fullword simply by ANDing the address. The processor might address them as fullwords internally. Suppose, for example, that the cache always loads fullwords. Your byte operations will always map perfectly to fullword cache operations, proving that certain
sets of bytes have certain relationships regardless of how the programmer
chooses to view them.

The cache line size has nothing to do with it. It might be 32-bytes long,
or some other size. That is simply a convenient method used to allow
indexing. If I know that all fetches of data will have an address that ends
in 0000, then I don't need to actually *store* those last 4 bits in my
index - thus saving considerable space. This has nothing to do with
whether the bytes in that 32-bytes has any relationship to any bytes before
or after it - except as defined by the cache controller.

This is what I meant by the relationship being defined by the process. The
memory controller has defined a relationship that has no meaning to any
other process. If I have a 30-byte string defined, it may or may not
require a single cache line to hold it, depending on how *it* is aligned.
The CPU will pull in as much data from cache (or memory) as the instruction
it is working on requires - no more, no less. Since data may or may not be
in cache, and since there are instructions that allow you to bypass cache -
cache access has nothing to do with how memory is defined.
A fullword is defined as four adjacent bytes aligned on a 4-byte boundary. It's *always* defined as such. Bytes 0, 1, 2, and 3 always form
a fullword and bytes 1, 2, 3, and 4 never do.

No. A fullword is a *FIELD* or a *DATA ELEMENT* or a *VALUE* that is four
bytes long and aligned on a word boundary. That is how it is defined. It
is not 4 bytes that have no relationship to each other.
Ahh, so some bytes can never be a fullword, regardless of what the programmer wants to do. Hmm, now why would that be?

You aren't paying attention.
No. "DS F" insists upon a fullword. 'DS XL4' requests 4 bytes that may or may not form a fullword.

Close. It may be on a fullword boundary, but there is no guarantee it will
be - so while you can 'use' it as a fullword, if someone adds a byte in
front of it without paying attention, the program won't work properly.
Therefore, it is not a fullword because it has no implied alignment.
Consider, for example, the following statement from a VAX manual, "On some systems, C aligns long word data items to fullword boundaries. On
such systems, a C structure may require an integral number of fullwords, even
if the actual data do not occupy all of the last fullword." What are we to make of this? How can a C structure even contain an integral number of fullword if the actual data is not defined to occupy
all of the last fullword?

You are talking about a compiler issue, not a 'memory' issue. Note that it
is talking about what C will do - not anything inherent in the memory
subsystem.
IBM defines a fullword as "4 bytes that start at an address evenly divisible by 4". Notice that it says nothing about how the program chooses to interpret them, simply that it must be 4 bytes and that it must start
at an address divisible by 4.

No, the z/OS Principles of Operation states

"Certain units of information must be on an integral boundary in storage. A
boundary is called integral for a unit of information