oN 11-Jun-04, rickman said:> Would that make 8 bits a dollar?Actually, I was in error, according to this link: http://www.geocities.com/fifth_grade_tpes/twobits.html From this it's clear that the usage predates the US silver dollar. -- Bill Posted with XanaNews Version 1.16.3.1
Octets with non-8 bit bytes...
Started by ●June 10, 2004
Reply by ●June 11, 20042004-06-11
Reply by ●June 11, 20042004-06-11
On Fri, 11 Jun 2004 22:23:05 GMT, "William Meyer" <wmeyerNO@SPAMsbcglobal.net> wrote:>oN 11-Jun-04, rickman said: > >> Would that make 8 bits a dollar? > >Yes, and comes from the practice of cutting a silver dollar into 8 >"bits" for making change.I think it was a Spanish "dollar", though. Pieces of eight. -- Al Balmer Balmer Consulting removebalmerconsultingthis@att.net
Reply by ●June 11, 20042004-06-11
rickman <spamgoeshere4@yahoo.com> wrote:> Hans-Bernhard Broeker wrote:[...]> > requirements. E.g. a C translation system targetting a 32-bit x86 PC > > yet using 19-bit chars, although obviously a total perversion, is > > quite certainly allowed by the C standard.> So how large is a byte on such a machine? I'm not clear if this is > 24 or 32 bits.Neither. It's 19 bits. By definition of "byte" in the C standard, one 'byte' is whatever the size of type char is. And, perverse as it may be, CHAR_BIT==19 is allowed. Even if the native addressing unit of the processor is, say, 11 bits ;-). Now, don't get me wrong, no compiler writer in a remotely sane state of mind would actually do that, but it's their customers and their own mental health that dictates that, not the definition of C. Read the fine print on pointer arithmetics in the C standard with such an implementation in mind, and many of the seemingly crazy clauses and restictions will suddenly begin to make sense... I guess this would be 32 bits since 24 bits would not be> "directly" addressable. How is that different from what Alan said?You're not getting my point. Which is that the C standard only demands that a byte is directly addressable, but not that everything directly addressable by the hardware must be a byte (by C's definition of the term) of its own. Otherwise, on 8051s a byte would have to be 1 bit wide, because they can address single bits. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
Reply by ●June 11, 20042004-06-11
Alan Balmer <albalmer@att.net> wrote:> On 11 Jun 2004 15:51:48 GMT, Hans-Bernhard Broeker > <broeker@physik.rwth-aachen.de> wrote:> > E.g. a C translation system targetting a 32-bit x86 PC > >yet using 19-bit chars, although obviously a total perversion, is > >quite certainly allowed by the C standard.> Providing that the 32-bit words are addressable in 19-bit chunks?Not really. Such a system, if someone were actually enough of a B.C.W.f.H. (a Bastard Compiler Writer from Hell) to create one, would simply discard 13 bits of each 32bit word. For the sheer fun of it, they might opt to use bits 0..4, 8..12, 16..20 and 24 .. 27. And all sizeof()s of C standard types other than the 'char' group might be different, prime numbers, each with it's own selection of bits used.> My head hurts.Relax. The chance you'll actually ever encounter such a beast are, luckily for all of us, quite negligible ;-) -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
Reply by ●June 12, 20042004-06-12
Guy Macon <http://www.guymacon.com> wrote in message news:<10ck1aasnts30f6@corp.supernews.com>...> > Following ?bit?, ?byte? and ?nybble? there have been quite a > few analogical attempts to construct unambiguous terms for > bit blocks of other sizes. All of these are strictly jargon, > not techspeak, and not very common jargon at that (most > hackers would recognize them in context but not use them > spontaneously). We collect them here for reference together > with the ambiguous techspeak terms ?word?, ?half-word?, > ?double word?, and ?quad? or quad word; some (indicated) > have substantial information separate entries. > > 2 bits: crumb, quad, quarter, tayste, tydbit, morsel > > 4 bits: nybble > > 5 bits: nickleDoes it matter if they are made of wood?> 10 bits: deckle12 bits?> 16 bits: playte, chawmp (on a 32-bit machine), word (on a 16-bit machine), > half-word (on a 32-bit machine). > > 18 bits: chawmp (on a 36-bit machine), half-word (on a 36-bit machine)What is it called on an 18-bit machine? 20 bits? 21 bits? 24 bits?> 32 bits: dynner, gawble (on a 32-bit machine), word (on a 32-bit machine), > longword (on a 16-bit machine). > > 36 bits: word (on a 36-bit machine) > > 48 bits: gawble (under circumstances that remain obscure) > > 64 bits: double word (on a 32-bit machine) quad (on a 16-bit machine) > > 128 bits: quad (on a 32-bit machine) > > The fundamental motivation for most of these jargon terms (aside from > the normal hackerly enjoyment of punning wordplay) is the extreme > ambiguity of the term word and its derivativesBest Wishes
Reply by ●June 12, 20042004-06-12
Guy Macon <http://www.guymacon.com> wrote in message news:<10chvgq33qr2v00@corp.supernews.com>...> "Octets" and "Bytes" are always 8 bits. The term you want is "Words."I can't imagine Octet meaning anything but 8 bits. However, over time, Byte has been used in many ways. There were a lot of 7 bit bytes at one time - a chunk big enough to hold an ASCII character in machines not measured in powers of 2. Word is almost certainly not the right term here. That usually implies the natural length of data elements on the machine - 16 bit words on 16 bit machines, 36 bit words on 36 bit machines, etc. Gee ain't terminology a pain :-) Regards, Steve
Reply by ●June 12, 20042004-06-12
On 11 Jun 2004 23:18:08 GMT, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:>Neither. It's 19 bits. By definition of "byte" in the C standard, >one 'byte' is whatever the size of type char is. And, perverse as it >may be, CHAR_BIT==19 is allowed.In fact CHAR_BIT==21 would even make a lot of sense. The Unicode Scalar Value (USV) is from 0x0..0x10FFFF, thus fitting nicely into 21 bits. Paul
Reply by ●June 12, 20042004-06-12
On 10 Jun 2004 16:59:49 -0700, usenet1@sanks.net (Alex Sanks) wrote:>Ok, I'm sure this has been beaten to death, but google, etc. found a >lot of descriptions of the problem but none of a portable solution. > >I'm working with some firmware drivers which are intended to be as >portable as possible. Data moves thru a switchable 8- or 16-bit data >bus chip (a USB device controller specifically). Performance is >critical so 16-bit is pretty much necessary. Following that example, >let's look at the USB mass storage class. You get commands from the >host in 31 octet command wrappers that look like this (endian issues >aside...): > >typedef struct >{ > u32 Signature; > u32 Tag; > u32 TransferLength; > u8 Flags; > u8 Lun; > u8 CommandLength; > u8 Command[15]; >} Cbw; > >If I have 8 bit data types that's easy enough to get and deal with. >But right now I'm working with a TMS320C55x variant with nothing >smaller than 16-bit data types. So naturally the 8 bit types get all >mixed up when I read them and when I send back similar data every >other octet is garbage. Some responses are filled at runtime, a few >are global constants. I can pack things early, but then I need to >unpack, modify, and repack. Or I can pack before transmission, but >that'd take a bite out of performance. Or I can break things down: >[ Stuff snipped] One portable way I have seen to force C to use a specific size is the following: typedef struct {unsigned data:8;} BYTE; The only problem is that if you define a variable as BYTE foo; you have to use it with following syntax foo.data=20; At least the compiler will have to do the masking etc. if necessary. Most reasonable compilers should generate the same code for a normal unsigned char variable and this type if it happens to be the same width. Regards Anton Erasmus
Reply by ●June 13, 20042004-06-13
On 10 Jun 2004 16:59:49 -0700, usenet1@sanks.net (Alex Sanks) wrote:> >I'm working with some firmware drivers which are intended to be as >portable as possible. Data moves thru a switchable 8- or 16-bit data >bus chip (a USB device controller specifically). Performance is >critical so 16-bit is pretty much necessary. Following that example, >let's look at the USB mass storage class. You get commands from the >host in 31 octet command wrappers that look like this (endian issues >aside...):I do not see much point in this discussion, unless you also consider the endian issues if you really want the code to be as portable as possible. If the endianess of the message and your hardware does not match, you sooner or later have to isolate the bytes and rearrange them, so why not do it immediately when assembling or disassembling the data frame. Postponing the endianess handling to a later stage only makes sense if the hardware contains a nice byte swap instruction (or an 8 bit rotate instruction on a 16 bit register), to be included with an in-line assembly statement, but this is not very portable :-). Paul
Reply by ●June 13, 20042004-06-13
Hans-Bernhard Broeker wrote:> > You're not getting my point. Which is that the C standard only > demands that a byte is directly addressable, but not that everything > directly addressable by the hardware must be a byte (by C's definition > of the term) of its own. Otherwise, on 8051s a byte would have to be > 1 bit wide, because they can address single bits.You're right, I'm not getting your point. If a byte must be directly addressable and be able to hold a character, then it would have to be either 24 or 32 bits on this hardware since 19 bits is not directly addressable. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX