 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
http://www.imgur.com/jvehe
Who do you believe?
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> http://www.imgur.com/jvehe
> Who do you believe?
Why for me?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> http://www.imgur.com/jvehe
>
>> Who do you believe?
>
> Why for me?
You're the one I most vividly remember complaining that disk drive
manufacturers say 1,000,000,000 bytes is a gigabyte?
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >> http://www.imgur.com/jvehe
> >
> >> Who do you believe?
> >
> > Why for me?
> You're the one I most vividly remember complaining that disk drive
> manufacturers say 1,000,000,000 bytes is a gigabyte?
That must be... at least 5 years ago or more?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> That must be... at least 5 years ago or more?
I thought it had come up repeatedly. :-)
I didn't mean to single you out personally in any way. I just thought you'd
be amused that the two search engines couldn't agree. :-)
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> I didn't mean to single you out personally in any way. I just thought you'd
> be amused that the two search engines couldn't agree. :-)
The question remains: Which one is correct?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> I didn't mean to single you out personally in any way. I just thought you'd
>> be amused that the two search engines couldn't agree. :-)
>
> The question remains: Which one is correct?
I find it interesting that google thinks 1024 meg is a gig, and wolfram
thinks 1000 meg is a gig. :-) Clearly science disagrees with computers.
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> The question remains: Which one is correct?
Whichever one you arbitrarily define as "correct".
Since "kilo" is an SI unit defined as 10^3, I guess that has historical
precedent. (I mean, without SI, would we even call it "kilobytes" in the
first place?)
IIRC, somebody somewhere wanted to start calling it KiB or something
stupid for when you actually mean 2^10...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> http://www.imgur.com/jvehe
>
> Who do you believe?
http://www27.wolframalpha.com/input/?i=100000MB+to+GiB
IMO it's a good idea to make them discreet like WA does - it makes
cross-calculating possible.
-Aero
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> IIRC, somebody somewhere wanted to start calling it KiB or something
> stupid for when you actually mean 2^10...
I think that "somebody somewhere" would be the International
Electrotechnical Commission.
The Institute of Electrical and Electronics Engineers also adopted
the naming convention in their IEEE 1541-2002 standard, as well as the
European Committee for Electrotechnical Standardization.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:4a43e8cf@news.povray.org...
> Orchid XP v8 <voi### [at] devnull> wrote:
> > IIRC, somebody somewhere wanted to start calling it KiB or something
> > stupid for when you actually mean 2^10...
> I think that "somebody somewhere" would be the International
> Electrotechnical Commission.
>
> The Institute of Electrical and Electronics Engineers also adopted
> the naming convention in their IEEE 1541-2002 standard, as well as the
> European Committee for Electrotechnical Standardization.
Good intentions, but "kilo binary binary digit" - what were they smoking?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >> http://www.imgur.com/jvehe
> >
> >> Who do you believe?
> >
> > Why for me?
>
> You're the one I most vividly remember complaining that disk drive
> manufacturers say 1,000,000,000 bytes is a gigabyte?
No, that would be me.
DIE, WA, DIE!!!!11
....
OK, I'm done now for at least a week... ;)
....Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/25/09 15:46, Darren New wrote:
> I find it interesting that google thinks 1024 meg is a gig, and wolfram
> thinks 1000 meg is a gig. :-) Clearly science disagrees with computers.
Do you mean the other way round? The link clearly shows Wolfram
thinking 1024 Megs is a Gig.
--
Marge: "When I married you, I knew we wouldn't live in luxury."
Homer: "And I kept that vow."
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz wrote:
> Do you mean the other way round? The link clearly shows Wolfram
> thinking 1024 Megs is a Gig.
Errr, no, I don't think so. The top half is where google says 100,000 megs
is 97 gig, implying 1024 meg to the gig. The bottom half is wolfram saying
100,000 meg is 100 gig. Hence, wolfram thinks 1000 meg is 1 gig, yes?
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
somebody <x### [at] ycom> wrote:
> Good intentions, but "kilo binary binary digit" - what were they smoking?
Where did you get that name? It's "kilo binary byte".
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Good intentions, but "kilo binary binary digit" - what were they smoking?
>
> Where did you get that name? It's "kilo binary byte".
I guess if you were talking about kiloBITS, then you would have "kilo
binary bit", and allegedly "bit" is short for "binary digit"... It's
tenuous though.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> I guess if you were talking about kiloBITS, then you would have "kilo
> binary bit", and allegedly "bit" is short for "binary digit"... It's
> tenuous though.
Btw, I have never understood why "kilobit" is so popular of a term.
Many things are measured in kilobits for no apparent reason, even though
other similar things are measured in kilobytes.
To me "kilobit" is a very confusing term. It doesn't tell my anything.
If someone says to me "the file was 150 kilobytes in size", I immediately
get a grasp of whether it's a large or a small file in that context, without
needing to think about it. However, if someone said "the file was 150 kilobits
in size" that would tell me nothing. I would have to perform some mental math
in order to comprehend the meaning. (Of course an easy approximation would be
to divide by 10... assuming the 25% error isn't significant in the context.
In many contexts that's a huge error.)
The only rational reason for using kilobits rather than kilobytes would
be if you need to express sizes which are not multiples of 8 bits. However,
in practice that's *never* the case. All practical sizes in computing are
multiples of 8 bits. There's absolutely no reason to use kilobits. There's
unnecessary accuracy in the unit.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Btw, I have never understood why "kilobit" is so popular of a term.
> Many things are measured in kilobits for no apparent reason, even though
> other similar things are measured in kilobytes.
The only place I've seen it used is in networking (most kinds of
networks transmit individual bits) and data compression (you might want
to send the data over a network or other transport, and you need to
compress it enough that the decoder can receive the data fast enough).
Haven't seen it anywhere else. (As you say, it wouldn't make much sense.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:4a449e36@news.povray.org...
> somebody <x### [at] ycom> wrote:
> > Good intentions, but "kilo binary binary digit" - what were they
smoking?
> Where did you get that name? It's "kilo binary byte".
"Kilo binary" as a prefix is not limited to bytes, another (less ambigious)
unit is the bit, hence kibibits, mebibits... etc.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/26/09 00:21, Darren New wrote:
> Errr, no, I don't think so. The top half is where google says 100,000
> megs is 97 gig, implying 1024 meg to the gig. The bottom half is wolfram
I can't read...
Anyway, to the best of my knowledge, kilobyte is the only one agreed
upon. In my high school textbooks, 1 KB was 1024 bytes, but 1 MB was
1000 KB (not 1e6 bytes).
--
Q: What do you call a half-dozen Indians with Asian flu?
A: Six sick Sikhs (sic).
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/26/09 05:31, Warp wrote:
> Btw, I have never understood why "kilobit" is so popular of a term.
> Many things are measured in kilobits for no apparent reason, even though
> other similar things are measured in kilobytes.
Like Andrew, I've seen it only in communications (and encoding is also
considered part of communications...).
Think modems (the phone ones). In the old days, it was all baud. 1 baud
is 1bit/s. It probably has stuck since.
Incidentally, I think with old modems, sending 1 byte didn't entail
sending 8 bits. I think they had two error correcting bits, making
sending 1 byte the same as 10 bits. If there's truth to that, I can see
why it'd make sense to specify bits.
--
Q: What do you call a half-dozen Indians with Asian flu?
A: Six sick Sikhs (sic).
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz wrote:
> Anyway, to the best of my knowledge, kilobyte is the only one
And if you look back at the instruction manuals for old 8-bit computers,
like the TRS-80 model 1 or the Apple ][, you'll see them described as having
65K of memory. I suspect nobody wanted to advertise 64K and have someone buy
the competitor's machine because it had 65K. :-)
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Btw, I have never understood why "kilobit" is so popular of a term.
It's a PSTN term. I.e., it's used in communication mediums like the public
switched telephone network where data isn't always byte-aligned. For
example, an American T1 circuit delivers 193 bits per frame.
Nowadays, it's more common to pad things out to the byte, since line speeds
are much higher. Nobody really tries to speed things up by using 5-bit
characters any more, so the need for kilobits is lessened.
Of course, audio is still in kilobytes per second, where a kilobyte is 1000
bytes and not 1024.
> in order to comprehend the meaning. (Of course an easy approximation would be
> to divide by 10... assuming the 25% error isn't significant in the context.
> In many contexts that's a huge error.)
The 25% is probably insignificant if the kilobits is communication speed,
because you have TCP overhead, framing overhead, etc.
> The only rational reason for using kilobits rather than kilobytes would
> be if you need to express sizes which are not multiples of 8 bits. However,
> in practice that's *never* the case.
Not any more.
http://en.wikipedia.org/wiki/Baudot_code
Of course, on serial lines, you have start bits and stop bits, so you're
really sending anywhere between 9 and 12 bits per character, sometimes
including even half-bits.
> All practical sizes in computing are
> multiples of 8 bits. There's absolutely no reason to use kilobits. There's
> unnecessary accuracy in the unit.
Again, yes, that's true now. Once people started mass-producing machines,
and the software got to where it was reasonable to run software from one
machine on another machine, 8-bit seemed to become most popular.
The intel 4004 was four bits, the PDP-8 was 12 bits, etc. Nowadays,
machines are powerful enough that you have protected memory mapped virtual
memory capable machines sitting in boxes with no user interfaces on them.
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz wrote:
> Think modems (the phone ones). In the old days, it was all baud. 1
> baud is 1bit/s. It probably has stuck since.
Technically, one baud is one symbol per second. A 9600bps modem is a 2400
baud modem with 2 symbols per baud.
> Incidentally, I think with old modems, sending 1 byte didn't entail
> sending 8 bits. I think they had two error correcting bits, making
> sending 1 byte the same as 10 bits. If there's truth to that, I can see
> why it'd make sense to specify bits.
One or two start bits to synchronize, one stop bit (or sometimes 1.5 stop
bits) to process, and perhaps a parity bit. No error correcting bits, but
parity might give you error detection if you're lucky.
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Mueen Nawaz wrote:
> > Think modems (the phone ones). In the old days, it was all baud. 1
> > baud is 1bit/s. It probably has stuck since.
>
> Technically, one baud is one symbol per second. A 9600bps modem is a 2400
> baud modem with 2 symbols per baud.
What? That's nonsense, the units don't match here. You probably mean 2 bits per
symbol.
But even after *prehistoric* times, when transmission was almost always binary
(i.e. 1 bit per symbol), the misconception of "baud = bps" stuck for quite a
while.
> > Incidentally, I think with old modems, sending 1 byte didn't entail
> > sending 8 bits. I think they had two error correcting bits, making
> > sending 1 byte the same as 10 bits. If there's truth to that, I can see
> > why it'd make sense to specify bits.
>
> One or two start bits to synchronize, one stop bit (or sometimes 1.5 stop
> bits) to process, and perhaps a parity bit. No error correcting bits, but
> parity might give you error detection if you're lucky.
The parity would typically be used with only 7 data bits.
But as a matter of fact, Kilo-, Mega- and GigaBITS are actually a much more
natural unit of measuring information storage or transmission capacity.
It's not only commonly used with transmission media, but also in
microelectronics, where (except in the "computer proper" business) you'll
virtually never find storage capacity specified in multiples of bytes *except*
when the storage device happens to be designed to access 8 bits in parallel. In
all other cases, chips are usually specified either at multiples of bits, or
multiples of a data word (the number of bits accessed in parallel), which would
typically be 1, 4, 8 (sometimes 9) or 16 bits.
A 2G DDR2 memory module should actually be designated as a 32Mx64 module. Would
be hard to explain to the customers, who are almost invariably locked with the
concept of a byte as the smallest unit of memory.
Happens to hardcore software developers, too. I once had some problems figuring
out why some intended-to-be-portable C software library I had developed didn't
run properly on a particular microcontroller - until finding out that a "char"
data type (the smallest data type in C, typically equalling a byte) was
actually 16 bits wide on that rascal. "A byte? What's that, Sir?" Doesn't make
life easier when you're developing a portable library for a communications
interface heavily based on the concept of the 8-bit thing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Mueen Nawaz wrote:
>>> Think modems (the phone ones). In the old days, it was all baud. 1
>>> baud is 1bit/s. It probably has stuck since.
>> Technically, one baud is one symbol per second. A 9600bps modem is a 2400
>> baud modem with 2 symbols per baud.
>
> What? That's nonsense, the units don't match here. You probably mean 2 bits per
> symbol.
Yes, sorry. Two bits per symbol aka two bits per baud.
> But even after *prehistoric* times, when transmission was almost always binary
> (i.e. 1 bit per symbol), the misconception of "baud = bps" stuck for quite a
> while.
Yes. Except, of course, in the phone company, where it actually made a
difference. :-)
> The parity would typically be used with only 7 data bits.
Usually, yes. Usually either 8-N-1 or 7-?-2, IME.
> all other cases, chips are usually specified either at multiples of bits, or
> multiples of a data word (the number of bits accessed in parallel), which would
> typically be 1, 4, 8 (sometimes 9) or 16 bits.
Yep. What about the serial type chips, like SD cards and stuff? How do they
get rated technically, do you know?
> run properly on a particular microcontroller - until finding out that a "char"
> data type (the smallest data type in C, typically equalling a byte) was
> actually 16 bits wide on that rascal.
Yeah. This is why Ada has different types for "a memory unit" and "an I/O unit".
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Warp wrote:
>> Darren New <dne### [at] sanrrcom> wrote:
>>> I didn't mean to single you out personally in any way. I just thought
>>> you'd be amused that the two search engines couldn't agree. :-)
>>
>> The question remains: Which one is correct?
>
> I find it interesting that google thinks 1024 meg is a gig, and wolfram
> thinks 1000 meg is a gig. :-)
Maybe Wolfram thinks 1000 megabytes are a gigabyte, and 1024 mibibytes are a
gibibyte?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Happens to hardcore software developers, too. I once had some problems
> figuring out why some intended-to-be-portable C software library I had
> developed didn't run properly on a particular microcontroller - until
> finding out that a "char" data type (the smallest data type in C,
> typically equalling a byte) was actually 16 bits wide on that rascal. "A
> byte? What's that, Sir?" Doesn't make life easier when you're developing a
> portable library for a communications interface heavily based on the
> concept of the 8-bit thing.
A C 'char' type MUST be exactly 1 byte long (in particular, sizeof(char)
MUST be 1). However, a C implementation may define "byte" with more than 8
bits.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> clipka wrote:
> > Happens to hardcore software developers, too. I once had some problems
> > figuring out why some intended-to-be-portable C software library I had
> > developed didn't run properly on a particular microcontroller - until
> > finding out that a "char" data type (the smallest data type in C,
> > typically equalling a byte) was actually 16 bits wide on that rascal. "A
> > byte? What's that, Sir?" Doesn't make life easier when you're developing a
> > portable library for a communications interface heavily based on the
> > concept of the 8-bit thing.
> A C 'char' type MUST be exactly 1 byte long (in particular, sizeof(char)
> MUST be 1). However, a C implementation may define "byte" with more than 8
> bits.
Does the C standard use the word "byte", or does it simply say that
sizeof(char) must always be 1 (without specifying a name for the unit)?
Of course if you need to take into account the amount of bits in your
integral types (including char) and you want your C program to be fully
portable even to exotic embedded systems, you have to use the CHAR_BIT
constant defined in limits.h rather than assume it's always 8.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/26/09 11:13, Darren New wrote:
> Mueen Nawaz wrote:
>> Think modems (the phone ones). In the old days, it was all baud. 1
>> baud is 1bit/s. It probably has stuck since.
>
> Technically, one baud is one symbol per second. A 9600bps modem is a
> 2400 baud modem with 2 symbols per baud.
Fine, be picky.<G>
I was taught it meant 1 cps (character per second) - which could have
been 1 bit/s, but not necessarily. I suppose character is the same as
your symbol.
It's just that in all the contexts that _I've_ used it, a baud was 1bit/s.
--
DO NOT REMOVE THIS TAG (UNDER PENALTY OF LAW)
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Does the C standard use the word "byte", or does it simply say that
> sizeof(char) must always be 1 (without specifying a name for the unit)?
It says byte, which is the smallest addressable unit of memory.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1336.pdf
That's why RFCs talk about octets and not bytes.
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz wrote:
> On 06/26/09 11:13, Darren New wrote:
>> Mueen Nawaz wrote:
>>> Think modems (the phone ones). In the old days, it was all baud. 1
>>> baud is 1bit/s. It probably has stuck since.
>>
>> Technically, one baud is one symbol per second. A 9600bps modem is a
>> 2400 baud modem with 2 symbols per baud.
>
> Fine, be picky.<G>
Hey, I worked for the guy who invented the 9600 bps modem. I had to be
picky. :-)
> I was taught it meant 1 cps (character per second) - which could
> have been 1 bit/s, but not necessarily. I suppose character is the same
> as your symbol.
Probably. The symbol is the smallest unit at the physical layer.
> It's just that in all the contexts that _I've_ used it, a baud was
> 1bit/s.
Yes, incorrectly so. :-) I still talk about 9600baud modems, unless i'm
being picky
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> It says byte, which is the smallest addressable unit of memory.
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1336.pdf
It's interesting that the standard doesn't specify how many bits there
should be in a byte (as it shouldn't), but later it specifies that the
maximum value an unsigned char type should be able to hold is 255, so
it's indirectly saying that a byte should be at least 8 bits. Likewise
it gives a minimum value of 8 for CHAR_BIT.
I suppose that if there exists a system with bytes smaller than 8 bits,
a C compiler for that system would slightly break the standard by necessity
(well, unless the 'char' type is made to consist of more than one physical
byte).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> but later it specifies that the
> maximum value an unsigned char type should be able to hold is 255
Of course I meant to write "at least" in between there.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I suppose that if there exists a system with bytes smaller than 8 bits,
> a C compiler for that system would slightly break the standard by necessity
Nah. You just wouldn't be able to address the smaller units. If you has
6-bit memory units, you'd have pointers to characters that increment by two
machine addresses on each ++, and you'd have 12 bits per char.
Altho, in truth, I expect they'd just break compatibility, rather than
actually follow the standard yet generate surprising machine code.
The real killer for such a system is the number of people who *do* assume
8-bit bytes. What happens when you have 10-bit characters and you call
write(14, "Zoop", 4)
and handle 14 is a TCP socket?
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I suppose that if there exists a system with bytes smaller than 8 bits,
> a C compiler for that system would slightly break the standard by
> necessity (well, unless the 'char' type is made to consist of more than
> one physical byte).
If there is a system with internal "bytes" smaller than 8 bits, it has to do
something different to make a conforming C implementation.
http://www.parashift.com/c++-faq-lite/intrinsic-types.html#faq-26.6
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> http://www.parashift.com/c++-faq-lite/intrinsic-types.html#faq-26.6
"""
The C++ language guarantees there are no bits between two bytes. This means
every bit in memory is part of a byte. If you grind your way through memory
via a char*, you will be able to see every bit.
"""
I find it hard to believe you could even enforce that in a language. I'm
quite sure there are architectures where C can run that have memory
unaddressable by a char*. Certainly there are bits in floating point
registers (or even regular CPU registers) that many architectures don't give
you addresses for. Memory in memory-mapped panes (i.e., addressing more bits
than you have address space for) would also seem to be outlawed.
"""
The C++ language guarantees there are no bits that are part of two distinct
bytes. This means a change to one byte will never cause a change to a
different byte.
"""
I wish he'd actually cited the part of the standard that says things like
this. It would be interesting to know how it was actually worded.
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> """
> The C++ language guarantees there are no bits that are part of two
> distinct bytes. This means a change to one byte will never cause a
> change to a different byte.
> """
>
> I wish he'd actually cited the part of the standard that says things
> like this. It would be interesting to know how it was actually worded.
Actually, thinking on this, it's obviously impossible to follow the
standards on any machine with virtual addressing, too. It's easy to tell
Linux (or at least the CPU, even if Linux prevents it) to map the same byte
to lots of different locations.
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Certainly there are bits in floating point
> registers (or even regular CPU registers) that many architectures don't give
> you addresses for. Memory in memory-mapped panes (i.e., addressing more bits
> than you have address space for) would also seem to be outlawed.
Then how do you copy blocks of memory from one place to another with a
function like memcpy()?
If an architecture cannot support memcpy() then that would certainly
break quite come C programs.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Actually, thinking on this, it's obviously impossible to follow the
> standards on any machine with virtual addressing, too.
Why? I thought the whole idea of virtual addressing is that non-contiguous
memory is made to *look* contiguous to a program, which is precisely what
the C standard requires. So virtual addressing *fixes* the problem rather
than *creating* it.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> The real killer for such a system is the number of people who *do* assume
> 8-bit bytes. What happens when you have 10-bit characters and you call
> write(14, "Zoop", 4)
> and handle 14 is a TCP socket?
Hell breaks loose?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Darren New wrote:
>> The real killer for such a system is the number of people who *do* assume
>> 8-bit bytes. What happens when you have 10-bit characters and you call
>> write(14, "Zoop", 4)
>> and handle 14 is a TCP socket?
>
> Hell breaks loose?
I don't know. But that's the problem Ada solves by separating out "bytes of
memory" from "bytes of I/O". Of course, as Warp points out, for 99% of the
population not writing code for embedded processors in weapons systems,
those two types are always the same and it's annoying as hell to write any
I/O stuff in Ada. :-)
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Actually, thinking on this, it's obviously impossible to follow the
>> standards on any machine with virtual addressing, too.
>
> Why? I thought the whole idea of virtual addressing is that non-contiguous
> memory is made to *look* contiguous to a program, which is precisely what
> the C standard requires. So virtual addressing *fixes* the problem rather
> than *creating* it.
I was addressing the part of the original comments that said the same bit
can't be part of two different bytes.
In any case, if I have more RAM than address space (say, a 6G box running
under WindowsXP-32), I can address all of memory, just not with a char*. So
VM both lets me have one byte in two places and also lets me have bytes that
no pointer can point to.
That's why I'm curious about exactly how the standards body worded these
things, rather than the FAQ-writer's take on it. I'm sure the standards body
isn't still back in a Z-80 mindset.
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Then how do you copy blocks of memory from one place to another with a
> function like memcpy()?
Why would memcpy be harder to implement than a while loop copying bytes?
My point is that if *no* program in that language can access those "hidden"
bits, how would your program know? Consider the bits hidden in (for example)
the processor registers. I worked on a mainframe where the registers were
mapped to addresses 0 thru 15. You could literally branch to instructions
stored in the registers. But you can't do that with AX/BX/SI/DI registers.
There's bits of "memory" that C can't address with a char*. Yet it isn't
problematic, because while memcpy() can't copy them, nothing else can see
that the copy can't copy them. I might have ECC bits or parity bits in my
memory, which C also can't address. It's not a problem for C.
Imagine if your C compiler was set up to only ever address even-numbered
bytes. Would you notice, other than running out of RAM twice as fast as you
thought you should? memcpy() would only copy even-numbered addresses, but
since nothing you do in the language would see odd-numbered addresses,
that's OK. (Until you share that memory with some other process via OS
primitives, but that isn't really relevant here.)
> If an architecture cannot support memcpy() then that would certainly
> break quite come C programs.
memcpy() doesn't need to copy all memory. It only needs to copy all
addressable memory.
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
