Из Википедии, свободной энциклопедии
Перейти к навигации Перейти к поиску
WikiProject Вычислительная техника / Сеть / Аппаратное обеспечение (Номинальный B-класс, высокая важность)
Значок WikiProjectЭта статья находится в рамках WikiProject Computing , совместной работы по расширению охвата компьютеров , вычислений и информационных технологий в Википедии. Если вы хотите принять участие, посетите страницу проекта, где вы можете присоединиться к обсуждению и увидеть список открытых задач.
Статья B-класса B Эта статья была оценена как B-Class по шкале качества проекта .
 Высокая Эта статья была оценена как высокая по шкале важности проекта .
Эта статья поддерживается целевой группой по сетевым технологиям (помечена как средняя ).
Эта статья поддерживается целевой группой по компьютерному оборудованию (помечена как высокая важность ).
 

Эта статья основана на материалах, взятых из Free On-line Dictionary of Computing до 1 ноября 2008 г. и включенных в соответствии с условиями «перелицензирования» GFDL версии 1.3 или новее.

Ошибка первоначальной публикации / атрибуции [ править ]

В статье говорится, что «Дэнни Коэн ввел термины с прямым порядком байтов и прямым порядком байтов в информатику для упорядочения данных в статье, опубликованной Internet Engineering Task Force (IETF) в 1980 году».

IETF была основана только в 1986 году и не могла быть первоначальным источником публикации. - Предшествующий неподписанный комментарий, добавленный HeidenChristenseun ( обсуждение • вклад ) 16:31, 20 сентября 2020 г. (UTC)

Я изменил его, чтобы просто сказать, что это было в заметке об эксперименте в Интернете, опубликованной в 1980 году, и не упомянул издателя. Все, кому интересно, как публиковались IEN, могут перейти по ссылке. Гай Харрис ( разговор ) 20:09, 20 сентября 2020 г. (UTC)

Порядок байтов - это не просто байты в слове [ править ]

Я устал бороться с этой битвой редактирования, но порядок следования байтов - это не просто «байты в слове», а скорее описывает произвольные наборы битов в битовом векторе. «Байты в слове» - наиболее распространенное использование, но это произвольно узкое определение оказывает нашим пользователям медвежью услугу. Дж. Майер ( разговорное ) 20:38, 13 ноября 2020 (UTC)

Джмайер , вы хотите привести цитату или две в поддержку этого? ~ Kvng ( обсуждение ) 14:43, 16 ноября 2020 (UTC)
Пожалуйста, не пытайтесь разыграть карточку цитирования, если большая часть этой статьи осталась без источника.
𝓦𝓲𝓴𝓲𝓹𝓮𝓭𝓲𝓪𝓘𝓼𝓝𝓸𝓽𝓟𝓮𝓮𝓻𝓡𝓮𝓿𝓲𝓮𝔀𝓮𝓭-𝓟𝓮𝓮𝓻𝓡𝓮𝓿𝓲𝓮𝔀𝓮𝓭𝓜𝓮𝓪𝓷𝓼𝓡𝓮𝓿𝓲𝓮𝔀𝓮𝓭𝓑𝔂𝓟𝓮𝓮𝓻𝓼𝓞𝓷𝓵𝔂 ( разговорное ) 22:08, 4 февраля 2021 (UTC)
Это обсуждалось ранее, но не было единого мнения, чтобы добавить это. Даже если текущие источники слабы, добавление информации, не имеющей источника, только ухудшает ситуацию, а не улучшает ситуацию. Без источников это не будет добавлено. - A D Monroe III ( разговор ) 02:31, 5 февраля 2021 (UTC)
@ Jmayer и Tgm1024 : Думаю, почти никто не согласен: порядок байтов - это не просто «байты в слове», а скорее описывает произвольные наборы битов в битовом векторе.
Но это первый«байты одним словом», а позже расширили на что угодно. Таким образом, в целях обсуждения можно сосредоточить первую половину на «порядке байтов в слове и битов в байте» (хотя «биты в байте» можно было бы поместить в отдельную статью), а затем дать общее представление о так чрезвычайно открытый конец, буквально и философски. - Nomen4Omen ( разговор ) 08:33, 5 февраля 2021 (UTC)
Ну, на некоторых процессорах это как минимум байты в двойном слове, четверном слове и октослове. Не говоря уже о том, где порядок байтов в слове отличается от порядка слов в двойном или четверном слове. Прямая битовая адресация встречается редко, но битовая адресация в слове не так уж и редка. Gah4 ( разговор ) 08:49, 5 февраля 2021 (UTC)

Пример Honeywell [ править ]

Пример Honeywell 316 кажется несовместимым с собственной документацией Honeywell [1] , которая показывает, что все типы данных (32-разрядные с фиксированной точкой, 32-разрядные целые числа двойной точности, 32-разрядные числа с плавающей запятой одинарной точности, 48-разрядные числа с плавающей запятой двойной точности) старшее 16-битное слово первым в памяти (страницы 2–4 и 2–5), что означает, что в примере (0x0A0B0C0D по состоянию на 2021-01-14) действительно будет {0B, 0A, 0D, 0C}. Кроме того, ширина шины составляет 16 бит, а 16-битные слова, по-видимому, являются минимальным адресуемым размером, и единственный способ прочитать то, что их документация называет «полусловами» (8 бит), - это загрузить 16-битное слово в регистр. а затем используйте одну из инструкций для полуслова (стр. 3-7). Таким образом, с точки зрения памяти, пример действительно будет {0x0A0B, 0x0C0D} (хотя он можетвозможно ли иметь 8-битную адресацию данных через выход на магнитную ленту?). Итак, если существуют машины Honeywell Series 16, соответствующие текущему примеру, то это не Honeywell 316, у которой порядок байтов меняет местами группы из 16 бит на 32 бита, а не из 8 бит на каждые 16 бит. Пикен ( разговор ) 07:41, 15 января 2021 (UTC) пикен

Я не вижу в документации ничего, что указывало бы на то, что 8-битные байты адресуются напрямую, поэтому любые соглашения о порядке байтов будут налагаться периферийными устройствами (именно здесь и пригодится магнитная лента; к сожалению, в документации Bitsavers, похоже, обсуждается только 7 -track, в котором фреймы ленты не соответствуют 8-битным байтам) или программным обеспечением, а не аппаратным обеспечением ЦП. Гай Харрис ( разговор ) 09:47, 15 января 2021 (UTC)
Порядок байтов бывает не только в 8-битных единицах. Если шесть битов выходят в одном порядке, это тоже будет порядком байтов. Хотя, когда размер слова кратен шести, это немного проще. Однако сейчас я не помню, как 36-битный PDP-10 записывает 9-дорожечную ленту. Gah4 ( разговор ) 15:58, 18 января 2021 (UTC)

использованная литература

  1. ^ https://archive.org/details/bitsavers_honeywells156316516PgmrRefNov70_4279319/page/n17/mode/2up

Числовые литералы и направления сдвига в языках программирования [ править ]

@ Винсент Лефевр :

  1. Насколько я понимаю, числовой литерал «12» обозначает число двенадцать почти во всех языках программирования. Поскольку языки программирования пишутся слева направо, «1» стоит перед (слева) «2», поэтому эту нотацию следует считать прямым порядком байтов, потому что «1» стоит перед «2». То же самое верно и для шестнадцатеричной системы счисления, где 0x102 определено для обозначения числа 258 dec : поскольку 1 стоит перед 0, стоит перед 1, 0x102 = 258.
    Я никогда не находил язык программирования, где числовой литерал «12» имел значение двадцать один. Даже если язык программирования использовался на машине с прямым порядком байтов.
  2. Точно так же, когда термин «вправо» используется с операциями битового сдвига, в руководствах он пишется «>>» (своего рода стрелки вправо).
    (даже в «Руководстве разработчика программного обеспечения для архитектур Intel 64 и IA-32, том 2 (2A, 2B и 2C): Справочник по набору инструкций, AZ» (PDF) ., который описывает машину с прямым порядком байтов)
и ВСЕГДА означает разделение. Например, 0x102 >> 8 = ⌊0x102 ÷ 256⌋ = 0x1 - это сдвиг вправо, хотя два байта внутри 2-байтового целого числа на компьютере Intel теперь содержат (0x01, 0x00), так что он, по-видимому, был смещен ВЛЕВО из своего исходный 0x102 = (0x02, 0x01). (Пожалуйста, помните: машина Intel - это машина с
прямым порядком байтов.) Таким образом, этот вид «сдвига вправо» является способом выражения с прямым порядком байтов. И этот способ говорить совершенно не зависит от целевой машины, для которой было написано руководство. Это то, что хотел сказать текст. - Nomen4Omen ( разговор ) 10:58, 18 января 2021 (UTC)
@ Nomen4Omen : Что касается 1, я согласен с аналогией, хотя я думаю, что термин "big-endian" на практике не используется для литералов (IMHO, источник был бы необходим, иначе эту аналогию можно было бы рассматривать как WP: OR ) . Что касается 2, я согласен с тем, что «<<» означает сдвиг влево, а «>>» означает сдвиг вправо (я полагаю, что эта нотация изначально пришла из языка программирования C), но я не вижу никакой связи с прямым порядком байтов; если такая связь существует, это необходимо уточнить, и также потребуется источник об этой связи. - Винсент Лефевр ( разговор ) 12:27, 18 января 2021 г. (UTC)

@ Винсент Лефевр : Хорошо, если вы не видите («не видите никакой связи с прямым порядком байтов»), что правый сдвиг байтовой последовательности
    (0x02, 0x01) >> 8
- это сдвиг вправо (целого числа 513 приводит к 2) на машине с прямым порядком байтов;
и сдвиг вправо той же последовательности байтов
    (0x02, 0x01) >> 8
- это сдвиг вправо (что интересно теперь целого числа 258, что приводит к 1) на машине с прямым порядком байтов, тогда я должен отказаться.
И я абсолютно уверен, что я не первый наблюдатель этого факта. Но тем не менее мне совершенно неинтересно искать литературу для бывших наблюдателей. - Nomen4Omen ( разговор ) 13:08, 18 января 2021 г. (UTC)

Когда IBM разрабатывала System / 360 с прямым порядком байтов более 50 лет назад, они знали, что метод прямого порядка байтов был правильным. Little endian иногда называют неправильным порядком байтов. Поскольку перенос в сложение (и вычитание) - это LSD в MSD, это немного проще сделать в системах с прямым порядком байтов, где адреса увеличиваются. Но деление выполняется с MSD на LSD, поэтому любая система, поддерживающая аппаратное разделение, может быть с прямым порядком байтов. Раньше отладка из шестнадцатеричных дампов была не такой уж редкостью, и чтение числовых значений стало проще в прямом порядке. Хотя VAX / VMS исправил это в своей программе DUMP, которая для каждой строки дает значение ASCII слева направо и шестнадцатеричное значение справа налево, а столбец адреса находится между ними. Программа unix od с параметром -x выводит шестнадцатеричные 16-битные слова, так что байты чтения выходят в неправильном порядке.Это усложняет, например, чтение данных ASCII в шестнадцатеричных дампах. В большинстве письменных (не связанных с программированием) языков теперь используются арабские цифры с прямым порядком байтов, даже если основной язык написан в другом направлении. Да, я endianist.Gah4 ( разговор ) 13:11, 18 января 2021 (UTC)
Многие ранние компьютеры были адресованы таким образом, что этой проблемы не возникало. Что ж, многие научные машины используют 36-битные слова с 6-битным набором символов. (Строчные буквы еще не были изобретены.) Насколько я знаю, программное обеспечение на этих машинах (без помощи оборудования) сохраняло текстовые данные с крайними левыми символами в более значимых цифрах. То есть с прямым порядком байтов. Кроме того, насколько мне известно, операции сдвига влево и вправо восходят к машинам с адресной адресной книгой. Поскольку, как написано на бумаге, << указывает влево, а >> указывает вправо, имена операторов C кажутся понятными. Мнемоники, такие как SHL и SHR, обычно использовались в ассемблерах для инструкций сдвига влево и вправо задолго до C. Да, в нашем мире обратный порядок байтов намного более естественен. Gah4 ( разговор) 13:22, 18 января 2021 г. (UTC)
В любом случае сдвиги определены для чисел, поэтому такие вещи, как «(0x02, 0x01) >> 8», ничего не значат. - Винсент Лефевр ( разговор ) 13:31, 18 января 2021 г. (UTC)
Сдвиги скважин могут применяться к битовым комбинациям, которые не обязательно имеют числовое значение. Биты в битовом изображении не являются числами, но их все же можно сдвинуть. MAC-адреса Ethernet также не являются числами. Gah4 ( разговор ) 13:47, 18 января 2021 (UTC)
Дело в том, что сдвиги имеют стандартные определения только для целых чисел через их двоичное представление. Возможно, вы захотите определить сдвиги для других типов абстрактных данных, но тогда вам нужно будет определить их, что не делается в этой статье. - Винсент Лефевр ( разговор ) 14:33, 18 января 2021 г. (UTC)
Полностью согласен с Gah4 . Хотя я бы не стал использовать выражение «неправильный порядок байтов». Но очевидно , что прямой порядок байтов является анти -correlated к обычному направлению письма, чтения, мышления, языки программирования придерживаться.
@ Винсент Лефевр :
Да, вы правы, смены определяются цифрами. Но числа представлены как байтовые последовательности и влияют на байтовые последовательности, которые хорошо известны и обусловлены определением. И нет необходимости определять эффекты, если на них можно смотреть.
Бессмысленно определять последствия такого определения, как вам кажется. Итак, если у вас есть 32-битное целое число, например, содержащее Unix(как уже упоминалось в статье ), и вы сдвигаете его вправо с прямым порядком байтов, то вы получаете ␣Uni(выглядит как сдвиг вправо), тогда как при небольшом - endian, nix␣который, по-видимому, является левым сдвигом. - Nomen4Omen (разговор ) 15:03, 18 января 2021 (UTC)
@ Nomen4Omen :Хорошо, если я правильно понимаю, у вас есть 4-символьный текст, хранящийся в памяти, который вы читаете как 32-битное целое число, затем вы выполняете 8-битный сдвиг вправо и сохраняете результат обратно в память, что является в итоге заметил как текст. Тогда да, на машине с прямым порядком байтов текст кажется сдвинутым на один символ вправо в сценарии LTR (но на один символ влево в сценарии RTL), а на машине с прямым порядком байтов текст выглядит так, как будто быть сдвинутым на один символ влево в сценарии LTR (но на один символ вправо в сценарии RTL). Однако это сильно отличается от того, что говорится в текущем тексте статьи (в котором просто упоминаются битовые сдвиги без объяснения причин). Однако, даже при правильном описании, я не думаю, что программисты делают такие вещи на практике (если некоторые делают, источник приветствуется), так что ям. Не уверен, что об этом стоит упомянуть, по крайней мере, в самом начале. Тем не менее, это не означает, что битовые сдвиги считаются прямым порядком байтов. -Винсент Лефевр ( разговорное ) 21:05, 18 января 2021 (UTC)

@ Винсент Лефевр :
Об этом уже упоминалось в статье . Как проблема - т.е. ловушка, в которую уже попали программисты. И это говорит нам о том, что очень немногие программисты должны писать программы, которые должны иметь дело с проблемой - и очень скоро, а именно во время тестирования, они заметят, что проблема существует. Но в статье эта проблема не представлена ​​систематически.
[Кстати, а вы знаете, как RTL-скрипт записывается в хранилище? На машине с прямым порядком байтов? Выяснить это непросто. Но есть веские основания полагать, что еврейская Библия хранится в хранилище, начиная с торы по младшим адресам. И поскольку сдвиг вправо при обратном порядке байтов сдвигается на старшие адреса, это остается сдвигом вправо - иТолькона экране он выглядит как сдвиг влево.] - Nomen4Omen ( разговор ) 21:51, 18 января 2021 г. (UTC)

@ Nomen4Omen : Нет, это не упоминается в статье (Кстати, ваша ссылка недействительна, похоже, вы оставили какой-то управляющий символ). В статье ничего не говорится об операциях битового сдвига . Скрипты LTR и RTL хранятся одинаково: один символ за другим, первый символ сохраняется первым (первый символ - это тот, который находится слева в сценарии LTR, а второй - справа в сценарии RTL), и такие скрипты можно даже смешивать. Есть специальные символы Unicode , чтобы указать направление письма: слева-направо знак и справа налево знак (смотрите примечание о памяти там компьютера). Также обратите внимание, что понятие левого и правого имеет смысл только при письме, например, на экране. -Винсент Лефевр ( разговорное ) 22:56, 18 января 2021 (UTC)