MMC and hex

Evans, Mark Mark_Evans at maxtor.com
Thu Jan 3 13:53:34 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Evans, Mark" <Mark_Evans at maxtor.com>
*
Hi Pat,

It's my opinion that we in T10 and T13 - particularly the editors - have
tried to be consistent about using numbers represented in different bases,
though maybe we should expand the descriptions of these in the "conventions"
clauses in the various standards.  Curtis Stevens makes a good start toward
this in T13/D1484D, BIOS Enhanced Disk Drive Services - 2 (EDD-2):

"Binary numbers use the digits: 0, 1. An example of a binary number is
0101b, this binary number is 5 decimal or 5h hexadecimal."

"Decimal numbers use the digits: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9. An example of
a decimal number is 1024, this is 010000000000b in binary and 400h in
hexadecimal."

"Hexadecimal numbers use the digits: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C,
D, E, F. An example of a hexadecimal number is 1Fh, this is 00011111b in
binary and 31 in decimal."

I also believe that the intent is that any binary or hexidecimal number
written in a standard represents all of the places for that number and is
always a positive number unless specifically defined as otherwise.  If 0000
0001b is intended to represent an eight-bit value, it should be written as
0000 0001b in the standard NOT 1b or 01b.  If 0000 000Fh is intended to
represent a four-byte value, it should be written as 0000 000Fh in the
standard NOT Fh or 0Fh.  It is also my opinion that any binary value that is
not represented by a multiple of four bits should never be represented in
hexidecimal (e.g., where 010b is the value in a three-bit field, this should
always be expressed as 010b, never as 2h).  Some words describing this could
also be added to the description of base representations in the
"conventions" clauses in the standards.

Does anyone out there disagree with this?  Please feel free to call or send
an email to me with your comments.

Regards,

Mark Evans
Maxtor Corporation
500 McCarthy Boulevard
Milpitas, CA 95035 USA
Tel:  408-894-5310
email:  mark_evans at maxtor.com

 -----Original Message-----
From: 	Pat LaVarre [mailto:LAVARRE at iomega.com] 
Sent:	Thursday, January 03, 2002 11:29 AM
To:	t10 at t10.org
Cc:	hlandis at ata-atapi.com
Subject:	Re: MMC and hex

* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
> > please copy hlandis at ata-atapi.com on any reply

Ok.

> If the spec says a field is '2F'h then it is saying it is '00101111'b.
> The spec should say the transmission order
> (bit 31 on line 31 or bit 31 first for serial).  

What about when MMC says x80?

In MMC does x80 always mean b1000:0000 or b0000:0000:1000:000 or ... and
never b1111:1111:1000:0000?

(If yes, then this is a claim that all hex literals in MMC are unsigned
two's complement.  Perhaps we can trust then that the width of every hex
literal is obvious from context to the most casual observer.)

> <JPScheible at aol.com> 01/03/02 11:03AM
>
> If you can represent a value in binary,
> then you can represent it in hex
> without knowing anything about its format
> (int, signed int, char, pig latin).
>
> Am I missing something?

Well, I don't like the way you said this.

I'm never comfortable talking just about values.  Down at the level of a
digital schematic, at the level of a bus trace, a number never just has a
value: always it has a value _and_ a width.

Q1) In converting between hex and binary, how do we cope if the width of the
binary value is not a multiple of four bits?

We have to agree how many bits we'll all agree to discard/fabricate
implicitly.

Q2) How do we cope if, to print the value as hex, someone stripped the sign
bits from a two's complement value?

We have to agree how to restore the sign bits.  We supply missing msb's by
copying the hi bit if the field is a signed two's complement value.  We
supply missing msb's by filling with zeroes if the field is an unsigned
two's complement value.  And so on.

For example, in C, what do the octal/decimal conversions:

        unsigned char ch1 = '\377'; int i1 = ch1; printf("%d ", i1);
        signed char ch2 = '\377'; int i2 = ch2; printf("%d ", i2);
        char ch3 = '\377'; int i3 = ch3; printf("%d\n", i3);

mean?

Platform by platform, I hear the answer varies.  I hear you'll see either
of:

        255 -1 -1 // Microsoft C++

        255 -1 255 // C elsewhere, Java if you say 16 bit Java char = C char

You also get 255 -1 -1 if you use the implicitly signed implicitly 8-bit
byte of Java in place of the C char type here.  You also get 255 -1 255 if
you use the implicitly unsigned 16-bit char of Java in place of the C char
type here.

Pat LaVarre


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list