Let's go ternary!
We'd be better off with 9-bit bytes
321–330 of 359 posts
Re: We'd be better off with 9-bit bytes
#322Earlier quoted context omitted.
We just need 3 valued electronics
But with 5 valued electronics, Up, down, left, right and charm... You could have the equivalent of 45-bit numbers ( 44 + parity ). And you could have the operands of two 15 bit numbers and their result encoded in 9 quint-bits or quits. Go pro or go home.
But, but, what about Strange?
Re: We'd be better off with 9-bit bytes
#323Hacker News needs, “potentially slop” button.
Re: We'd be better off with 9-bit bytes
#324Earlier quoted context omitted.
Brillant, that 36 bits would be three bytes. "DEC's 36-bit computers were primarily the PDP-6 and PDP-10 families, including the DECSYSTEM-10 and DECSYSTEM-20. These machines were known for their use in university settings and for pioneering work in time-sharing operating systems. The PDP-10, in particular, was a popular choice for research and development, especially in the field of artificial intelligence. " "Compu…
Personally I think 12/48/96 would be more practical than the current 8/32/64. 32 bits is almost trivially easy to overflow whereas 48 bits is almost always enough when working with integers. And 64 bits is often insufficient or at least uncomfortably tight when packing bits together. Whereas by the time you've blown past 96 you should really just bust out the arrays and eat any overhead. Similarly I feel that 24 bits…
12 bit color would have been great. In the old days 4 bits for each of RGB, or even packing 2 pixels per byte. Today 12 bit per channel would be awesome, although high end cameras seem to be at 14 (which doesn't fit bytes well either).
Instruction sets - 12 bits for small chips and 24 for large ones. RISC-V instructions encode better in 24bits if you use immediate data after the opcode instead of inside it.
Physical memory is topping out near 40bits of address space and some virtual address implementations don't even use 64 bits on modern systems.
Floating point is kinda iffy. 36 bits with more than 24bit mantissa would be good. not sure what would replace doubles.
Re: We'd be better off with 9-bit bytes
#325Earlier quoted context omitted.
We likely wouldn’t use base64 at all in that case, but Base256. But also more of Europe would have fit in ASCII and Unicode would be a few years behind.
The point of Base64 is to represent binary data using a familiar character repertoire. At least for the latin-script world, any collection of 256 characters won’t be a familiar character repertoire.
Who told you that? Don’t talk to that person anymore.
Base64 and uuencode before it are about transmitting binary data over systems that cannot handle binary. There are a bunch of systems in the early Internet that could only communicate 7 bits per byte, which is why uuencode uses only printable low ASCII characters. Has nothing to do with familiarity.
Systems that supported eight bits per byte were referred to as “8 bit clean”, to distinguish them from legacy systems you might still have to support.
PNG file format was specced in 1995, and it was still worried about 8 bit clean transmission. The first byte of the PNG magic number has the high bit set because they didn’t want the decoder to even have to bother with broken PNG files.
> Base64 is also widely used for sending e-mail attachments, because SMTP – in its original form – was designed to transport 7-bit ASCII characters only. Encoding an attachment as Base64 before sending, and then decoding when received, assures older SMTP servers will not interfere with the attachment.
I think it’s reasonable to assume that in a world with 9 bit bytes, someone may have chosen 8 bits for SMTP, or moved to 8 bit sooner. Which would give you at least Base128.
Re: We'd be better off with 9-bit bytes
#326Non-power-of-2 sizes are awkward from a hardware perspective. A lot of designs for e.g. optimized multipliers depend on the operands being divisible into halves; that doesn't work with units of 9 bits. It's also nice to be able to describe a bit position using a fixed number of bits (e.g. 0-7 in 3 bits, 0-31 in 5 bits, 0-63 in 6 bits), e.g. to represent a number of bitwise shift operations, or to select a bit from a…
We just need 3 valued electronics
Technically e would be best IIRC, but hard to implement, so 3 is the closest.
Re: We'd be better off with 9-bit bytes
#327Earlier quoted context omitted.
The fixed point TI dsp chips always had a long int that was 48. Intel had 84 bit floating point registers before simd registers took over. And the pdp-11... Powers of two aren't as ubiquitous as it seems. If anything, the hardware uses whatever sizes it wants and that gets abstracted from the rest of the world by compilers and libraries.
The pdp-11 was 16-bit.
Thanks! I picked the only pdp that was actually a power of 2.
Re: We'd be better off with 9-bit bytes
#328Earlier quoted context omitted.
>Usually the size of general purpose registers is what defines the bitness of a CPU The Motorola 68000 has 32-bit registers but it's usually considered a 16-bit CPU because it has 16-bit ALU and 16-bit data bus (both internal and external).
Motorola 68k is a curious case because it originally was supposed to be a 16bit cpu, not 32bit, and the 24bit addressing that ignored upper 8 bits didn't help the perception. Ultimately, 68k being "16bit" is a marketing thing from home computers that upgraded from 8bit 6502 and the like to m68k but didn't use it fully.
That is an odd case.
I'd still call it a 32-bit CPU as it had 32-bit registers and instructions (and not just a few special case 32-bit instructions IIRC). Like the 386SX it had a 16-bit external data bus, but some of its internal data routes were 16-bit also (where the 386SX had the full 32-bit core of a 386, later renamed 386DX, with the changes needed to change the external data bus) as were some of its ALUs hence the confusion abaout its bit-ness.
Re: We'd be better off with 9-bit bytes
#329Earlier quoted context omitted.
>Usually the size of general purpose registers is what defines the bitness of a CPU The Motorola 68000 has 32-bit registers but it's usually considered a 16-bit CPU because it has 16-bit ALU and 16-bit data bus (both internal and external).
Motorola 68k is a curious case because it originally was supposed to be a 16bit cpu, not 32bit, and the 24bit addressing that ignored upper 8 bits didn't help the perception. Ultimately, 68k being "16bit" is a marketing thing from home computers that upgraded from 8bit 6502 and the like to m68k but didn't use it fully.
Well, the 6809 was basically the same in these respects.
Internal registers are 16 bit, with the accumulator (A) being provisioned as two 8 bit registers (A, B) as needed. Index X, Y, Stack, User Stack, PC, are all 16 bit registers.
The Hitachi 6309, adds to that with up to 32 bit register sizes in specific cases.
In any case, the ALU and data transfers are 8 bits and I am not sure I ever saw the 6809 referenced as a 16 bit device.
Maybe 16 bit curious, LMAO.
Re: We'd be better off with 9-bit bytes
#330Earlier quoted context omitted.
Motorola 68k is a curious case because it originally was supposed to be a 16bit cpu, not 32bit, and the 24bit addressing that ignored upper 8 bits didn't help the perception. Ultimately, 68k being "16bit" is a marketing thing from home computers that upgraded from 8bit 6502 and the like to m68k but didn't use it fully.
That is an odd case. I'd still call it a 32-bit CPU as it had 32-bit registers and instructions (and not just a few special case 32-bit instructions IIRC). Like the 386SX it had a 16-bit external data bus, but some of its internal data routes were 16-bit also (where the 386SX had the full 32-bit core of a 386, later renamed 386DX, with the changes needed to change the external data bus) as were some of its ALUs hence…
Would you call the 6809 a 16 bit device?