Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #5047 > unrolled thread

64-bit bytes

Back to article view | Back to comp.programming

Contents

  64-bit bytes fir <profesor.fir@gmail.com> - 2015-01-05 01:38 -0800
    Re: 64-bit bytes robin.vowels@gmail.com - 2015-01-08 00:46 -0800
      Re: 64-bit bytes fir <profesor.fir@gmail.com> - 2015-01-08 00:53 -0800
        Re: 64-bit bytes robin.vowels@gmail.com - 2015-01-11 15:46 -0800
          Re: 64-bit bytes Richard Heathfield <invalid@see.sig.invalid> - 2015-01-12 00:32 +0000
            Re: 64-bit bytes BartC <bc@freeuk.com> - 2015-01-12 01:35 +0000
              Re: 64-bit bytes Richard Heathfield <invalid@see.sig.invalid> - 2015-01-12 09:07 +0000
                Re: 64-bit bytes BartC <bc@freeuk.com> - 2015-01-12 11:43 +0000
                  Re: 64-bit bytes Richard Heathfield <invalid@see.sig.invalid> - 2015-01-12 11:59 +0000
                    Re: 64-bit bytes BartC <bc@freeuk.com> - 2015-01-12 12:21 +0000
                      Re: 64-bit bytes Mark Carroll <mtbc@bcs.org> - 2015-01-12 12:36 +0000
                        Re: 64-bit bytes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-01-12 14:15 +0000
                          Re: 64-bit bytes BartC <bc@freeuk.com> - 2015-01-12 14:34 +0000
                            Re: 64-bit bytes "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2015-01-12 16:35 +0100
                              Re: 64-bit bytes BartC <bc@freeuk.com> - 2015-01-12 17:42 +0000
                                Re: 64-bit bytes "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2015-01-12 19:11 +0100
                                  Re: 64-bit bytes BartC <bc@freeuk.com> - 2015-01-12 19:18 +0000
                                    Re: 64-bit bytes "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2015-01-12 21:34 +0100
                                      Re: 64-bit bytes BartC <bc@freeuk.com> - 2015-01-12 22:01 +0000
                            Re: 64-bit bytes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-01-13 00:51 +0000
                      Re: 64-bit bytes Richard Heathfield <invalid@see.sig.invalid> - 2015-01-12 13:18 +0000
                        Re: 64-bit bytes BartC <bc@freeuk.com> - 2015-01-12 14:16 +0000
                          Re: 64-bit bytes Richard Heathfield <invalid@see.sig.invalid> - 2015-01-12 14:48 +0000
                            Re: 64-bit bytes BartC <bc@freeuk.com> - 2015-01-12 15:05 +0000
                            Re: 64-bit bytes Robert Wessel <robertwessel2@yahoo.com> - 2015-01-12 15:43 -0600
                Re: 64-bit bytes Kaz Kylheku <kaz@kylheku.com> - 2015-01-12 21:05 +0000
                  Re: 64-bit bytes Richard Heathfield <invalid@see.sig.invalid> - 2015-01-12 22:12 +0000
              Re: 64-bit bytes "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2015-01-12 10:12 +0100
            Re: 64-bit bytes robin.vowels@gmail.com - 2015-01-11 20:56 -0800
              Re: 64-bit bytes Richard Heathfield <invalid@see.sig.invalid> - 2015-01-12 09:19 +0000
                Re: 64-bit bytes robin.vowels@gmail.com - 2015-01-12 06:22 -0800
                  Re: 64-bit bytes Richard Heathfield <invalid@see.sig.invalid> - 2015-01-12 14:51 +0000
                    Re: 64-bit bytes robin.vowels@gmail.com - 2015-01-12 15:46 -0800
                    Re: 64-bit bytes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-01-13 01:16 +0000
                      Re: 64-bit bytes Richard Heathfield <invalid@see.sig.invalid> - 2015-01-13 01:53 +0000
                        Re: 64-bit bytes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-01-13 13:28 +0000
                          Re: 64-bit bytes Richard Heathfield <invalid@see.sig.invalid> - 2015-01-13 13:57 +0000
                            Re: 64-bit bytes "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2015-01-13 15:32 +0100
                            Re: 64-bit bytes fir <profesor.fir@gmail.com> - 2015-01-13 06:33 -0800
                              Re: 64-bit bytes BartC <bc@freeuk.com> - 2015-01-13 16:41 +0000
                                Re: 64-bit bytes fir <profesor.fir@gmail.com> - 2015-01-13 15:25 -0800
                                  Re: 64-bit bytes BartC <bc@freeuk.com> - 2015-01-13 23:49 +0000
                                    Re: 64-bit bytes fir <profesor.fir@gmail.com> - 2015-01-13 23:57 -0800

Page 1 of 3  [1] 2 3  Next page →

#5047 — 64-bit bytes

(move here if someona like to comment on this
specyfic topic, also mirror it to comp.programming in hope to move up that group for more c-unrelated programming topic discussions)


> like it was already mantioned by some (and i also think so) byte is more like obsolete today times 
> it was invented (afaik) to get off variable bit-field length troubles, now it got back with some variable byte feild length troubles 
> (i mean mostly decoding instruction stream in x86 which must be done in sub nanosecond scale and is quite complex in x86 asm) 
> How much it would be simpler if byte would have 32 bits - instruction opcode would fit in one byte adress in one or two, that would be great simplicity; also joining such 32bit byte with utf-32 would let sword cut such many utf-8 utf-16 utf-32 dillemates.. also endiannes/low endian hell would drop down a bit, as most values would not be reversed 
> just becouse you will se a regular bytes often 
> - so definitely x86 like machines should go onto 32 byte way 

yet more option indeed is 64-bit byte option, 
this sounded a bit crazy at first*, but is some interesting option too 

*the problem is that this will waste a bandwidth in noticable way, i think 32 bit byte in this time will not result in any waste at all but 64-bit will do; On the other side it can have something oldschool new-technology feeling, and you can trade some waste for newteh simplicity sometimes, why no, we're not so poor anyway to not be able to toy with some interesting machines sometimes ;/ (but usilng 64-bit byte i mean like supplementary machines 
like some mainframes or something like that ;/ probably not home stuff

[toc] | [next] | [standalone]

#5060

On Monday, January 5, 2015 8:38:32 PM UTC+11, fir wrote:
> (move here if someona like to comment on this
> specyfic topic, also mirror it to comp.programming in hope to move up that group for more c-unrelated programming topic discussions)
> 
> 
> > like it was already mantioned by some (and i also think so) byte is more like obsolete today times 
> > it was invented (afaik) to get off variable bit-field length troubles,

Nothing of the sort.
The byte of 8 bits was introduced in order to make it easier to process
characters.
Earlier machines having words of 32 bits and more (e.g., 60 bits)
handled characters clumsily.
It was far easier to have character-handling instructions access
those 8-bit characters directly (and not as a part of a much longer word).

> now it got back with some variable byte feild length troubles 
> > (i mean mostly decoding instruction stream in x86 which must be done in sub nanosecond scale and is quite complex in x86 asm) 
> > How much it would be simpler if byte would have 32 bits - instruction opcode would fit in one byte adress in one or two, that would be great simplicity; also joining such 32bit byte with utf-32 would let sword cut such many utf-8 utf-16 utf-32 dillemates.. also endiannes/low endian hell would drop down a bit, as most values would not be reversed 
> > just becouse you will se a regular bytes often 
> > - so definitely x86 like machines should go onto 32 byte way 
> 
> yet more option indeed is 64-bit byte option, 
> this sounded a bit crazy at first*, but is some interesting option too 
> 
> *the problem is that this will waste a bandwidth in noticable way,
> i think 32 bit byte

A byte is 8 bits.

> in this time will not result in any waste at all but 64-bit will do;
> On the other side it can have something oldschool new-technology feeling,
> and you can trade some waste for newteh simplicity sometimes, why no,
> we're not so poor anyway to not be able to toy with some
> interesting machines sometimes ;/ (but usilng 64-bit byte i mean
> like supplementary machines 
> like some mainframes or something like that ;/ probably not home stuff

[toc] | [prev] | [next] | [standalone]

#5061

W dniu czwartek, 8 stycznia 2015 09:46:52 UTC+1 użytkownik robin....@gmail.com napisał:
> On Monday, January 5, 2015 8:38:32 PM UTC+11, fir wrote:
> > (move here if someona like to comment on this
> > specyfic topic, also mirror it to comp.programming in hope to move up that group for more c-unrelated programming topic discussions)
> > 
> > 
> > > like it was already mantioned by some (and i also think so) byte is more like obsolete today times 
> > > it was invented (afaik) to get off variable bit-field length troubles,
> 
> Nothing of the sort.
> The byte of 8 bits was introduced in order to make it easier to process
> characters.
> Earlier machines having words of 32 bits and more (e.g., 60 bits)
> handled characters clumsily.
> It was far easier to have character-handling instructions access
> those 8-bit characters directly (and not as a part of a much longer word).
> 

have you some quotation or something like this.. in wiki byte is talking about variable length fields.. and logicallt when computers are build there has to be decision or use variable lenght fields or fixed length fields,
this is base decistion and i think was taken
thus byte appeard





> > now it got back with some variable byte feild length troubles 
> > > (i mean mostly decoding instruction stream in x86 which must be done in sub nanosecond scale and is quite complex in x86 asm) 
> > > How much it would be simpler if byte would have 32 bits - instruction opcode would fit in one byte adress in one or two, that would be great simplicity; also joining such 32bit byte with utf-32 would let sword cut such many utf-8 utf-16 utf-32 dillemates.. also endiannes/low endian hell would drop down a bit, as most values would not be reversed 
> > > just becouse you will se a regular bytes often 
> > > - so definitely x86 like machines should go onto 32 byte way 
> > 
> > yet more option indeed is 64-bit byte option, 
> > this sounded a bit crazy at first*, but is some interesting option too 
> > 
> > *the problem is that this will waste a bandwidth in noticable way,
> > i think 32 bit byte
> 
> A byte is 8 bits.
> 
> > in this time will not result in any waste at all but 64-bit will do;
> > On the other side it can have something oldschool new-technology feeling,
> > and you can trade some waste for newteh simplicity sometimes, why no,
> > we're not so poor anyway to not be able to toy with some
> > interesting machines sometimes ;/ (but usilng 64-bit byte i mean
> > like supplementary machines 
> > like some mainframes or something like that ;/ probably not home stuff

[toc] | [prev] | [next] | [standalone]

#5086

On Thursday, January 8, 2015 at 7:53:54 PM UTC+11, fir wrote:
> W dniu czwartek, 8 stycznia 2015 09:46:52 UTC+1 użytkownik r.nospam@gmail.com napisał:
> > On Monday, January 5, 2015 8:38:32 PM UTC+11, fir wrote:
> > > (move here if someona like to comment on this
> > > specyfic topic, also mirror it to comp.programming in hope to move up that group for more c-unrelated programming topic discussions)
> > > 
> > > 
> > > > like it was already mantioned by some (and i also think so) byte is more like obsolete today times 
> > > > it was invented (afaik) to get off variable bit-field length troubles,
> > 
> > Nothing of the sort.
> > The byte of 8 bits was introduced in order to make it easier to process
> > characters.
> > Earlier machines having words of 32 bits and more (e.g., 60 bits)
> > handled characters clumsily.
> > It was far easier to have character-handling instructions access
> > those 8-bit characters directly (and not as a part of a much longer word).
> > 
> 
> have you some quotation or something like this.. in wiki byte is talking about variable length fields.. and logicallt when computers are build there has to be decision or use variable lenght fields or fixed length fields,
> this is base decistion and i think was taken
> thus byte appeard

A byte is a fixed-length field of 8 bits.

[toc] | [prev] | [next] | [standalone]

#5087

robin.vowels@gmail.com wrote:

<snip>
 
> A byte is a fixed-length field of 8 bits.

...except when it isn't. For example, some embedded systems ("freestanding 
implementations") use 32-bit bytes. At least one of the Analog SHARC chips 
uses 32-bit bytes.

IEC 80000-13 defines the byte to be 8 bits, but there are other 
international standards that use more flexible definitions (e.g. ISO/IEC 
9899, which requires only that a byte must be *at least* 8 bits).

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#5088

On 12/01/2015 00:32, Richard Heathfield wrote:
> robin.vowels@gmail.com wrote:
>
> <snip>
>
>> A byte is a fixed-length field of 8 bits.
>
> ...except when it isn't. For example, some embedded systems ("freestanding
> implementations") use 32-bit bytes. At least one of the Analog SHARC chips
> uses 32-bit bytes.
>
> IEC 80000-13 defines the byte to be 8 bits, but there are other
> international standards that use more flexible definitions (e.g. ISO/IEC
> 9899, which requires only that a byte must be *at least* 8 bits).

Nonsense. A byte is generally understood to be 8 bytes.

I have a memory stick plugged into my PC, and on it it says it's 4GB - 4 
gigabytes. What are the chances of that being anything other 32G bits? 
Be nice if it was perhaps 128G bits, but it isn't!

The same goes for specifying the capacity of most types of memory.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#5090

BartC wrote:

> On 12/01/2015 00:32, Richard Heathfield wrote:
>> robin.vowels@gmail.com wrote:
>>
>> <snip>
>>
>>> A byte is a fixed-length field of 8 bits.
>>
>> ...except when it isn't. For example, some embedded systems
>> ("freestanding implementations") use 32-bit bytes. At least one of the
>> Analog SHARC chips uses 32-bit bytes.
>>
>> IEC 80000-13 defines the byte to be 8 bits, but there are other
>> international standards that use more flexible definitions (e.g. ISO/IEC
>> 9899, which requires only that a byte must be *at least* 8 bits).
> 
> Nonsense.

Nonsense it may be. ISO/IEC 9899 it most certainly is.

> A byte is generally understood to be 8 bytes.

And you accuse /me/ of nonsense? Furrfu.

> 
> I have a memory stick plugged into my PC, and on it it says it's 4GB - 4
> gigabytes. What are the chances of that being anything other 32G bits?

There's almost certainly a railway not too far away from you. What are the 
chances that it's the same gauge as the rest of the railways in your local 
governmental district? By the same reasoning, therefore, all the railways in 
the world have the same gauge. Except that they don't, of course. Non-8-bit-
byte systems do actually exist, your incredulity notwithstanding.

> Be nice if it was perhaps 128G bits, but it isn't!
> 
> The same goes for specifying the capacity of most types of memory.

So either you agree that some bytes are other than 8 bits wide, or you are 
arguing that most == all.
 
-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#5093

On 12/01/2015 09:07, Richard Heathfield wrote:

>> The same goes for specifying the capacity of most types of memory.
>
> So either you agree that some bytes are other than 8 bits wide, or you are
> arguing that most == all.

Only that some types of memory devices (such as the individual DRAM 
chips I used to buy) might have a capacity specified in bits.

The more consumer-oriented modules, or even magnetic or optical media 
where the data is stored serially, have capacities expressed in bytes.

They don't usually need to elaborate on what a byte actually is; the 
8-bit byte is a de facto standard.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#5094

BartC wrote:

> On 12/01/2015 09:07, Richard Heathfield wrote:
> 
>>> The same goes for specifying the capacity of most types of memory.
>>
>> So either you agree that some bytes are other than 8 bits wide, or you
>> are arguing that most == all.
> 
> Only that some types of memory devices (such as the individual DRAM
> chips I used to buy) might have a capacity specified in bits.
> 
> The more consumer-oriented modules, or even magnetic or optical media
> where the data is stored serially, have capacities expressed in bytes.
> 
> They don't usually need to elaborate on what a byte actually is; the
> 8-bit byte is a de facto standard.

I would certainly agree that the 8-bit byte is a de facto standard. But the 
existence of a standard does not imply universal conformance. Nor does it 
help us to understand the historical context of the term.

I find it curious that many people are determined to restrict the term 
"byte" to mean "exactly eight bits", when doing so (a) makes the term 
redundant (because we already have "octet" to mean "exactly eight bits"), 
and (b) hampers our ability to describe alternative computer architectures. 
What advantage does this restriction give us that compensates for the loss 
of flexibility?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#5095

On 12/01/2015 11:59, Richard Heathfield wrote:
> BartC wrote:

>> They don't usually need to elaborate on what a byte actually is; the
>> 8-bit byte is a de facto standard.
>
> I would certainly agree that the 8-bit byte is a de facto standard. But the
> existence of a standard does not imply universal conformance. Nor does it
> help us to understand the historical context of the term.

> I find it curious that many people are determined to restrict the term
> "byte" to mean "exactly eight bits", when doing so (a) makes the term
> redundant (because we already have "octet" to mean "exactly eight bits"),

Not as many people know about 'octet', and 'byte' is now too firmly 
established. Its abbreviation 'o' is also not as clear or as familiar as 
'B' (actually, I only found out what it was a minute ago from Wikipedia!).

> and (b) hampers our ability to describe alternative computer architectures.
> What advantage does this restriction give us that compensates for the loss
> of flexibility?

We already have 'word' for that, where you generally need to qualify its 
size, outside of a specific context such as a language.

(In the languages I create, a 'word' type was 16 bits, up to around 
2002. Then it was upgraded to 32 bits (but is unlikely to be upgraded 
again to 64). A 'byte' type however has always been 8 bits.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#5096

BartC <bc@freeuk.com> writes:

> On 12/01/2015 11:59, Richard Heathfield wrote:
(snip)
>> and (b) hampers our ability to describe alternative computer architectures.
>> What advantage does this restriction give us that compensates for the loss
>> of flexibility?
>
> We already have 'word' for that, where you generally need to qualify its 
> size, outside of a specific context such as a language.
(snip)

Exactly. For instance, Erlang, being designed to run on various odd
computer architectures, lets one ask,

	erlang:system_info(wordsize)

which is documented as,

] Returns the size of Erlang term words in bytes as an integer, i.e. on
] a 32-bit architecture 4 is returned, and on a pure 64-bit architecture
] 8 is returned.

which clearly implies 8-bit bytes.

(Erlang's other memory queries tend to be in terms of words.)

-- Mark

[toc] | [prev] | [next] | [standalone]

#5098

Mark Carroll <mtbc@bcs.org> writes:

> BartC <bc@freeuk.com> writes:
>
>> On 12/01/2015 11:59, Richard Heathfield wrote:
> (snip)
>>> and (b) hampers our ability to describe alternative computer architectures.
>>> What advantage does this restriction give us that compensates for the loss
>>> of flexibility?
>>
>> We already have 'word' for that, where you generally need to qualify its 
>> size, outside of a specific context such as a language.
> (snip)
>
> Exactly. For instance, Erlang, being designed to run on various odd
> computer architectures, lets one ask,
>
> 	erlang:system_info(wordsize)
>
> which is documented as,
>
> ] Returns the size of Erlang term words in bytes as an integer, i.e. on
> ] a 32-bit architecture 4 is returned, and on a pure 64-bit architecture
> ] 8 is returned.
>
> which clearly implies 8-bit bytes.

I would not call 32-bit and 64-bit architectures "odd"!  What would it
do on a 36-bit or a 60-bit machine?

Not knowing anything about Erlang I'm curious about the need to make any
assumption about bytes at all.  Why does the function not return the
number of value bits?  Surely that's both more flexible an just as
useful?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#5101

On 12/01/2015 14:15, Ben Bacarisse wrote:
> Mark Carroll <mtbc@bcs.org> writes:

>> Exactly. For instance, Erlang, being designed to run on various odd
>> computer architectures, lets one ask,
>>
>> 	erlang:system_info(wordsize)
>>
>> which is documented as,
>>
>> ] Returns the size of Erlang term words in bytes as an integer, i.e. on
>> ] a 32-bit architecture 4 is returned, and on a pure 64-bit architecture
>> ] 8 is returned.
>>
>> which clearly implies 8-bit bytes.
>
> I would not call 32-bit and 64-bit architectures "odd"!  What would it
> do on a 36-bit or a 60-bit machine?

At the time the language was created (1986 according to Wikipedia), it 
must already have been clear that the machine word sizes the language 
would be likely to run on, would be 16 or 32 or 64 bits. In other words, 
be based on powers-of-two and therefore multiples of a byte.

This is unlike C which is still (even now) expected to work on all sorts 
of genuinely odd microprocessor architectures.

(BTW what would C's sizeof(int) return on a 36-bit or 60-bit machine?)

> Not knowing anything about Erlang I'm curious about the need to make any
> assumption about bytes at all.  Why does the function not return the
> number of value bits?  Surely that's both more flexible an just as
> useful?

The number of bytes must be more useful overall, it you wished to find 
out how much RAM is taken up by N words, or how much disk space, or the 
size of a record; you rarely do these calculation in bits.

You can derive a byte-count from the number of bits, but this is an 
extra, inconvenient step. And you might then be obliged to consider the 
possibility of a byte-width not dividing exactly into the word size, or 
explaining why you've hard-coded a divide-by-eight into a calculation! 
It just more untidy.

Anyway after nearly 30 years, it doesn't sound as though it's done the 
language much harm.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#5105

On Mon, 12 Jan 2015 14:34:17 +0000, BartC wrote:

> On 12/01/2015 14:15, Ben Bacarisse wrote:

>> Not knowing anything about Erlang I'm curious about the need to make any
>> assumption about bytes at all.  Why does the function not return the
>> number of value bits? Surely that's both more flexible an just as
>> useful?

In Ada all sizes are in bits.

> The number of bytes must be more useful overall, it you wished to find 
> out how much RAM is taken up by N words, or how much disk space, or the 
> size of a record; you rarely do these calculation in bits.

Ever heard about packed arrays, bit fields, Boolean? The following program:

with Ada.Text_IO; use Ada.Text_IO;
procedure Test is
begin
   Put_Line (Integer'Image (Boolean'Size) & " bit");
end Test;

prints:

 1 bit

How many bytes is that?

> You can derive a byte-count from the number of bits, but this is an 
> extra, inconvenient step.

You must do it for bytes as well if machine requires certain data types be
aligned.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#5110

On 12/01/2015 15:35, Dmitry A. Kazakov wrote:
> On Mon, 12 Jan 2015 14:34:17 +0000, BartC wrote:
>
>> On 12/01/2015 14:15, Ben Bacarisse wrote:
>
>>> Not knowing anything about Erlang I'm curious about the need to make any
>>> assumption about bytes at all.  Why does the function not return the
>>> number of value bits? Surely that's both more flexible an just as
>>> useful?
>
> In Ada all sizes are in bits.

I thought you said elsewhere that integer types are defined as ranges, 
not how many bits they should occupy.

>> The number of bytes must be more useful overall, it you wished to find
>> out how much RAM is taken up by N words, or how much disk space, or the
>> size of a record; you rarely do these calculation in bits.
>
> Ever heard about packed arrays, bit fields, Boolean? The following program:
>
> with Ada.Text_IO; use Ada.Text_IO;
> procedure Test is
> begin
>     Put_Line (Integer'Image (Boolean'Size) & " bit");
> end Test;
>
> prints:
>
>   1 bit
>
> How many bytes is that?

1/8?

Obviously the number of bytes occupied for a single, isolated bit is not 
meaningful. (And the chances are that such a standalone bit variable 
will occupy a whole byte or word anyway.)

You have to take these things into account.

If I write in one my languages:

println int.bytes
println byte.bytes
println bit.bytes

I get: 4, 1 and 1. But if I write:

println int.bitwidth
println byte.bitwidth
println bit.bitwidth

Then I get 32, 8 and 1.

If you created a function in Ada to return the size of a type in terms 
of 8-bit bytes, and the result had to be an integer, then you will get 
similar problems.

In my case, I decided that rounding up was the most useful, considering 
for example that so many library functions work in whole bytes (I can't 
allocate 14.625 bytes, it has to be 15).

With packed bit arrays, the number of bytes are also rounded up to whole 
bytes (but needs extra care when working with in-place bit-slices which 
are not aligned on a byte or word. However you rarely need to worry 
about this stuff as don't need think in terms of bytes.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#5112

On Mon, 12 Jan 2015 17:42:42 +0000, BartC wrote:

> On 12/01/2015 15:35, Dmitry A. Kazakov wrote:
>> On Mon, 12 Jan 2015 14:34:17 +0000, BartC wrote:
>>
>>> On 12/01/2015 14:15, Ben Bacarisse wrote:
>>
>>>> Not knowing anything about Erlang I'm curious about the need to make any
>>>> assumption about bytes at all.  Why does the function not return the
>>>> number of value bits? Surely that's both more flexible an just as
>>>> useful?
>>
>> In Ada all sizes are in bits.
> 
> I thought you said elsewhere that integer types are defined as ranges, 
> not how many bits they should occupy.

Sure. You are confusing a type declaration:

   type T is range 1..100;

with a type's representation aspect:

   T'Size   -- The least number of bits needed for an instance of T

and with an typed object's representation aspect. T'Size is not object's
size:

   X : T;

   X'Size -- The actual number of bits used for this instance of T.

>>> The number of bytes must be more useful overall, it you wished to find
>>> out how much RAM is taken up by N words, or how much disk space, or the
>>> size of a record; you rarely do these calculation in bits.
>>
>> Ever heard about packed arrays, bit fields, Boolean? The following program:
>>
>> with Ada.Text_IO; use Ada.Text_IO;
>> procedure Test is
>> begin
>>     Put_Line (Integer'Image (Boolean'Size) & " bit");
>> end Test;
>>
>> prints:
>>
>>   1 bit
>>
>> How many bytes is that?
> 
> 1/8?

That is not integer.
 
> Obviously the number of bytes occupied for a single, isolated bit is not 
> meaningful. (And the chances are that such a standalone bit variable 
> will occupy a whole byte or word anyway.)

That is why in Ada T'Size and X'Size are different beasts. But you are
wrong. A bit in a packed array or structure can be exactly 1 bit long.

> You have to take these things into account.
> 
> If I write in one my languages:
> 
> println int.bytes
> println byte.bytes
> println bit.bytes
> 
> I get: 4, 1 and 1. But if I write:
> 
> println int.bitwidth
> println byte.bitwidth
> println bit.bitwidth
> 
> Then I get 32, 8 and 1.

Which is evidently inconsistent with your definition of byte = 8 * bits.

> If you created a function in Ada to return the size of a type in terms 
> of 8-bit bytes, and the result had to be an integer, then you will get 
> similar problems.

That would be Float (T'Size)/8.0 without rounding and (T'Size+7)/8 with
rounding. Except that usefulness of such functions is questionable.

When you write a custom storage pool in Ada, the compiler passes the
required number of storage elements (note, not bits nor bytes) to your
implementation of Allocate.

8 bits
1 byte
1 Storage_Element

are potentially all different.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#5114

On 12/01/2015 18:11, Dmitry A. Kazakov wrote:
> On Mon, 12 Jan 2015 17:42:42 +0000, BartC wrote:

>> println int.bytes
>> println byte.bytes
>> println bit.bytes
>>
>> I get: 4, 1 and 1. But if I write:
>>
>> println int.bitwidth
>> println byte.bitwidth
>> println bit.bitwidth
>>
>> Then I get 32, 8 and 1.
>
> Which is evidently inconsistent with your definition of byte = 8 * bits.

Not with the last lot of bit-widths.

>> If you created a function in Ada to return the size of a type in terms
>> of 8-bit bytes, and the result had to be an integer, then you will get
>> similar problems.
>
> That would be Float (T'Size)/8.0 without rounding and (T'Size+7)/8 with
> rounding. Except that usefulness of such functions is questionable.
>
> When you write a custom storage pool in Ada, the compiler passes the
> required number of storage elements (note, not bits nor bytes) to your
> implementation of Allocate.
>
> 8 bits
> 1 byte
> 1 Storage_Element
>
> are potentially all different.

So? I can write this:

a := new(array, bit, -41..75)

This yields bounds of (-41,75), and a length of 117 /bits/. It is 
possible to work with bits, bit-fields and bit-arrays without worrying 
about bytes (although the byte size of that array if I was interested 
would be 15 bytes rather than 14.625).

So it's possible work with bits within software even though the 
underlying machine is byte-oriented, as most are. It's just not 
necessary to work exclusively with bits as you are suggesting.

And the same byte-oriented approach is used with memory and storage 
devices, even though the underlying hardware /is/ bit-oriented!

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#5118

On Mon, 12 Jan 2015 19:18:59 +0000, BartC wrote:

> On 12/01/2015 18:11, Dmitry A. Kazakov wrote:
>> On Mon, 12 Jan 2015 17:42:42 +0000, BartC wrote:
> 
>>> println int.bytes
>>> println byte.bytes
>>> println bit.bytes
>>>
>>> I get: 4, 1 and 1. But if I write:
>>>
>>> println int.bitwidth
>>> println byte.bitwidth
>>> println bit.bitwidth
>>>
>>> Then I get 32, 8 and 1.
>>
>> Which is evidently inconsistent with your definition of byte = 8 * bits.
> 
> Not with the last lot of bit-widths.

Of course it is:

int.bytes = 4 & int.bitwidth = 32 => byte = 32/4 = 8 bits
bit.bytes = 1 & bit.bitwidth = 1 => byte = 1/1 = 1 bit

Either your program lies or else X.bytes and X.bits measure different
things. "bit" left of ".bytes" is not like "bit" left of ".bitwidth" q.e.d.

>>> If you created a function in Ada to return the size of a type in terms
>>> of 8-bit bytes, and the result had to be an integer, then you will get
>>> similar problems.
>>
>> That would be Float (T'Size)/8.0 without rounding and (T'Size+7)/8 with
>> rounding. Except that usefulness of such functions is questionable.
>>
>> When you write a custom storage pool in Ada, the compiler passes the
>> required number of storage elements (note, not bits nor bytes) to your
>> implementation of Allocate.
>>
>> 8 bits
>> 1 byte
>> 1 Storage_Element
>>
>> are potentially all different.
> 
> So? I can write this:
> 
> a := new(array, bit, -41..75)
> 
> This yields bounds of (-41,75), and a length of 117 /bits/. It is 
> possible to work with bits, bit-fields and bit-arrays without worrying 
> about bytes (although the byte size of that array if I was interested 
> would be 15 bytes rather than 14.625).

And the bitwidth of 15 bytes is 117? See, byte is not 8 bits again!

> So it's possible work with bits within software even though the 
> underlying machine is byte-oriented, as most are. It's just not 
> necessary to work exclusively with bits as you are suggesting.

It is absolutely necessary as you just have explained: the logical width of
the array is 117 bits, its storage representation width is 15 storage
elements. (Bytes have nothing to do with all this)

> And the same byte-oriented approach is used with memory and storage 
> devices, even though the underlying hardware /is/ bit-oriented!

This is yet another data type. In Ada the unit used for external storage is
called Stream_Element. So:

1. Bit
2. Byte (unused)
3. Storage_Element - RAM items
4. Stream_Element - I/O items, e.g. octet

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#5123

On 12/01/2015 20:34, Dmitry A. Kazakov wrote:
> On Mon, 12 Jan 2015 19:18:59 +0000, BartC wrote:
>> On 12/01/2015 18:11, Dmitry A. Kazakov wrote:
>>> On Mon, 12 Jan 2015 17:42:42 +0000, BartC wrote:

>>>> println bit.bytes
>>>>
>>>> I get: 4, 1 and 1. But if I write:

>>> Which is evidently inconsistent with your definition of byte = 8 * bits.
>>
>> Not with the last lot of bit-widths.
>
> Of course it is:
>
> int.bytes = 4 & int.bitwidth = 32 => byte = 32/4 = 8 bits
> bit.bytes = 1 & bit.bitwidth = 1 => byte = 1/1 = 1 bit
>
> Either your program lies or else X.bytes and X.bits measure different
> things. "bit" left of ".bytes" is not like "bit" left of ".bitwidth" q.e.d.

I explained my rationale for returning the byte-size of a single bit as 
1 rather than 0 or anything else.

But, one advantage of having your own language is that things can be 
changed rapidly (it helps that I've never yet used the feature anywhere):

println bit.bytes

now displays 0.125. And the calculations are consistent.

>> a := new(array, bit, -41..75)

> And the bitwidth of 15 bytes is 117? See, byte is not 8 bits again!

It's now 14.625.

Of course the number of bits in a byte does not depend on exactly how my 
language works. It was 8 yesterday and it is still 8 today.

> It is absolutely necessary as you just have explained: the logical width of
> the array is 117 bits, its storage representation width is 15 storage
> elements.

It actually uses 16 bytes, for reasons the programmer doesn't need to 
now (32 to get more technical). But to copy all the bit data will 
require a minimum of 15 whole bytes. Now however he will need to round 
up the number of bytes. (Actually, now I've made my point, I might 
change it back again...)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#5126

BartC <bc@freeuk.com> writes:

> On 12/01/2015 14:15, Ben Bacarisse wrote:
>> Mark Carroll <mtbc@bcs.org> writes:
>
>>> Exactly. For instance, Erlang, being designed to run on various odd
>>> computer architectures, lets one ask,
>>>
>>> 	erlang:system_info(wordsize)
>>>
>>> which is documented as,
>>>
>>> ] Returns the size of Erlang term words in bytes as an integer, i.e. on
>>> ] a 32-bit architecture 4 is returned, and on a pure 64-bit architecture
>>> ] 8 is returned.
>>>
>>> which clearly implies 8-bit bytes.
>>
>> I would not call 32-bit and 64-bit architectures "odd"!  What would it
>> do on a 36-bit or a 60-bit machine?
>
> At the time the language was created (1986 according to Wikipedia), it
> must already have been clear that the machine word sizes the language
> would be likely to run on, would be 16 or 32 or 64 bits. In other
> words, be based on powers-of-two and therefore multiples of a byte.

I agree it's a reasonable limitation.  I'm just saying that these are
not examples of odd computer architectures.

> This is unlike C which is still (even now) expected to work on all
> sorts of genuinely odd microprocessor architectures.
>
> (BTW what would C's sizeof(int) return on a 36-bit or 60-bit machine?)

The only conforming C compiler I know of for such a systems reports 4
for sizeof(int) because ints have 36 bits and bytes 9.  It's for a system
running on Unisys machines.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.programming

csiph-web