[swift-evolution] Why hard-code octet-sized bytes?

Robert Widmann devteam.codafi at gmail.com
Fri Jun 17 23:49:01 CDT 2016


Old old old architectures.  We're talking Multics days.

~Robert Widmann

2016/06/17 21:35、David Sweeris via swift-evolution <swift-evolution at swift.org> のメッセージ:

> IIRC, a bunch of Ye Olde systems used 6-bit bytes. And I think 36-bit ints were used in a few architectures, but don't quote me on that.
> 
> - Dave Sweeris
> 
>> On Jun 17, 2016, at 22:48, Félix Cloutier via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Out of curiosity, can you name an architecture that doesn't use 8-bit bytes?
>> 
>> Félix
>> 
>>> Le 17 juin 2016 à 13:01:33, Daryle Walker via swift-evolution <swift-evolution at swift.org> a écrit :
>>> 
>>> When I first looked into Swift, I noticed that the base type was called “UInt8” (and “Int8”) and not something like “Byte.”  I know modern computers have followed the bog standard 8/16/32(/64) architecture for decades, but why hard code it into the language/library?  Why should 36-bit processors with 9-bit bytes, or processors that start at 16 bits, be excluded right off the bat?  Did you guys see a problem with how (Objective-)C(++) had to define its base types in a mushy way to accommodate the possibility non-octet bytes?
>>> 
>>> BTW, is there an equivalent of CHAR_BIT, the number of bits per byte, in the library?  Or are we supposed to hard code an “8”?
>>> 
>>>>>> Daryle Walker
>>> Mac, Internet, and Video Game Junkie
>>> darylew AT mac DOT com 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160617/6c023851/attachment.html>


More information about the swift-evolution mailing list