3 ms·
They need not know by heart, but they should be able to find out if necessary. Reminder that 8 bit bytes were standardized in 1993 (ISO/IEC 2382-1:1993 accordi
by tpxl 4y ago
They need not know by heart, but they should be able to find out if necessary.
Reminder that 8 bit bytes were standardized in 1993 (ISO/IEC 2382-1:1993 according to Wiki), and before that it was common to have bytes be 6, 8 or 9 bits.
- defrost 4y agoIncorrect. From (the latest version of the standard you gave) > byte > string that consists of a number of bits, treated as a unit, and usually representing a character or a part of a character > Note 1 to entry: The number of bits in a byte is fixed for a given data processing system. > Note 2 to entry: The number of bits in a byte is usually 8. Note Carefully: "usually" ie. Just as it has always been - 16bits in a byte for any CPU with a smallest addresable unit being 16 bits, or 32, or 12, or 24. As a C programmer I've worked with bytes of many different bit numbers, hence the need for a C compiler constant to define such things. Today it is typical for 32 and 64 bit DSP processing chips (eg the TI DSP families) to have 32 | 64 bits per byte.
- WithinReason 4y agoOn GPUs the smallest addressable unit is a DWORD (32 bits) but no one calls them a byte.
- defrost 4y agoAny C | C++ compiler targeting that GPU will call that 32bit blob a CHAR and will have the constant CHAR_BIT sety to 32 in (c)limits.h Within the low level standard C programming commmunity the terms Byte and Char are interchangable and vary by architecture or domain (8 bits in a networking application domain, potentially more bits on various target architectures).
- WithinReason 4y agoIn OpenCL C a char refers to 8 bits: https://registry.khronos.org/OpenCL/specs/2.2/html/OpenCL_C.html#restrictions https://registry.khronos.org/OpenCL/specs/2.2/html/OpenCL_C....
- defrost 4y agoIn a somewhat qualified and frequently struck through manner if you parse the entire document. > OpenCL (Open Computing Language) is a framework for writing programs that execute across heterogeneous platforms consisting of central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), field-programmable gate arrays (FPGAs) and other processors or hardware accelerators. Here's the thing, any processing done on 32 bit | 64 bit RISC like DSP chips can talk about having an 8 bit char .. but these will be embedded within a 64 bit "smallest addressable unit" as the hardware pointers iterate from one 64 bit (or 32 bit) chunk to the next. There are also (within the DSP components) restrictions on masking out 8 bit segments of a 64 bit "smallest addressable chunk" as the hardware is optimised for integer and float operations w/out a care for delicate little 8 bit operations. In other words, in a hybrid Franken-beast creating "images" from convolutions and signal operations, the hardware that writes packed image formats with OpenCL char types will not (can not) be DSP type hardware that convolves and fouriers the computations that create the "now package me" pre-final image sets. Returning to the base point, the mere fact that sometime a char is 8 bits ion no way requires a char to always be 8 bits .. if you read about it is most generally defined as "at least 8 bits".