Обсуждение:Порядок байтов

message: __TOC__

message: В этом же виде числа записывает и человек
Вообще-то в разных культурах по-разному. Очевидный контрпример - арабские цифры в сочетании с арабской письменностью. Maxim Razin 07:25, 14 августа 2006 (UTC)
replies: text: Википедия:Правьте смело. В смысле, если что не так, исправляйте. George Shuklin 10:55, 14 августа 2006 (UTC)
replies: text: :М.б. "В большинстве современных культур" ? --Goldminer 15:47, 18 августа 2006 (UTC)

text: :Внёс замечание по этому поводу. Netch 08:41, 18 декабря 2010 (UTC)
thread_title:  числа записывает и человек 

message: А их надо так обширно писать?  George Shuklin 07:53, 15 августа 2006 (UTC)
thread_title:  Результаты запуска testendian.c 

message: А нельзя по-русски-то написать? Что ещё за big-endian? Кстати, для терминов Свифта есть перевод "остроконечники" и "тупоконечники". Dims 09:01, 15 августа 2006 (UTC)
replies: text: Этот вопрос обсуждали. К сожалению, в русской практике нет соответствующего общеупотребимого термина. Русский перевод Свифта остаётся переводом только книги, этот перевод не переносится на порядок байтов :) George Shuklin 09:25, 15 августа 2006 (UTC)
replies: text: : А где обсуждали-то? Если нет термина, то надо использовать словосочетания из других слов. Ведь у нас тут статья о порядке байтов и в ней разделы. Разделы не обязаны называться односложным термином или сленговым выражением. Раздел может называться, например, "от старшего к младшему", "от младшего к старшему" или типа того. Я вот, например, миллион раз «озабачивался» вопросом, как в данном конкретном компьютере расположены байты числа, но эти слова первый раз слышу. Это означает, что данный вопрос индифирентен этим терминам. Более того, это означает, что в наших книжках как-то всё-таки об этом говорится, пусть и не односложными терминами. Значит, так и надо написать в статье. С чего бы это мы начали уже английскими словами изъясняться!? Кстати, я не уверен, что в английском эти термину широко употребляются. Опять-таки потому, что читал некоторое количество англояязычных книжек по аппаратному обеспечению, но таких терминов не запомнил. Dims 15:43, 15 августа 2006 (UTC)
replies: text: :: В книге Дж. Свифта я нашёл упоминание о Big-endians (но нет упоминания Little-endians, и тем более нет упоминания остроконечников и тупоконечников). Поэтому, считаю, что совершил ошибку, поспешно указав, что термин Little-endians был введён Дж. Свифтом (хотя введение термина Little-endians напрашивается само собой).

text: :: Термины big-endian и little-endian широко используются в англоязычной литературе!

text: ::Приведу только несколько источников, связанных с аппаратным обеспечением:

text: ::* MIPS32 Architecture for programmers: Volume 1, Introduction to MIPS32 Architecture — данная спецификация хорошо раскрывает обсуждаемый вопрос.

text: ::* PCI Local Bus Specification v.2.2

text: ::* RapidIO Interconnect Specification Part 1: Input/Output Logical Specification, rev.1.3

text: ::* The SPARC architecture manual: version 8

text: ::Выше перечислены только спецификации шин и процессорных архитектур. Если же говорить о документации на конкретные СБИС, использующие данные шины или архитектуры, то, как правило, в спецификациях конкретных СБИС есть параграф, в котором рассматриваются вопросы адресации и порядка байт (endianity).

text: ::Кроме того, эти термины широко используются в англоязычной литературе, посвященной вопросам системного программирования (для ядра операционной системы, и в особенности для драйверов устройств,  данный вопрос актуален):

text: ::* U. Vahalia, UNIX internals: the new frontiers, Prentice Hall, 1996

text: ::*   Jonathan Corbet, Alessandro Rubini, Greg Kroah-Hartman  Linux Device Drivers, 3rd edition, Chapter 11: Data Types in the Kernel

text: ::* названия (и, тем более содержимое) некоторых заголовочных файлов в исходных текстах ядра Linux 2.4.16 очень красноречивы:

text: :: linux-2.6.16-rc5 $ ls include/linux/byteorder/*endian*

text: :: include/linux/byteorder/big_endian.h

text: :: include/linux/byteorder/little_endian.h

text: :: include/linux/byteorder/pdp_endian.h

text: :: Frantony 14:38, 16 августа 2006 (UTC)
replies: text: ::: Ну, тупоконечники, разумеется, встречаются в русском переводе http://www.lib.ru/INOOLD/SWIFT/gulliver.txt. Остроконечников там тоже нет, потому что разбивать яйца с узкого конца -- это совершенно естественно и никакого названия не требует, а вот те, кто разбивают их с тупого конца -- эти составляют гнусную секту тупоконечников. :) Dims 17:28, 16 августа 2006 (UTC)

text: ::: Насчёт широты использования. Всё равно. Не можем же мы использовать английское слово просто потому, что оно у них широко используется? Dims 17:28, 16 августа 2006 (UTC)
replies: text: :::: Я полностью согласен с тем, что чте необходимо использовать русские слова (мне не нравится, когда вместо ОЗУ пишут RAM), но в данном конкретном случае это проблематично.

text: :::: Считаю, что содержательная и грамотная статья с вкраплениями англоязычных терминов лучше, чем короткая и бессодержательная, но использующая только рускоязычную терминологию.

text: :::: Статья Порядок байт требует, в первую очередь, улучшения содержания, а не терминологии.

text: :::: Frantony 17:57, 16 августа 2006 (UTC)

text: ::: Постоянно натыкаюсь на эти понятия (Big-endian и little-endian) в документации по Java, и статья помогла разобраться, в чем дело. Я считаю, что использовать нужно официальные названия (даже если они на английском - особенно если они на английском:)), потому что гораздо легче связать то, с чем сталкивался, и то, что написано в статье. "Порядок от младшего к старшему" - это самодескриптивная фраза, а не термин.
thread_title:  А нельзя по-русски-то написать? 

message: Статья должна называться «порядок разрядов»
Из него уже следует порядок байтов в целых числах
SergeyPosokhov 15:05, 15 августа 2006 (UTC)
replies: text: C разрядами - не пройдёт, так как в байте разряды пишутся от старшего к младшему. Serguei S. Dukachev 06:05, 21 августа 2006 (UTC)
См. Bit_Endianness
Frantony 15:18, 16 августа 2006 (UTC)
thread_title:  Я бы переименовал 

message: Так как описано в статье не работает:
$ cat /proc/cpuinfo | grep '^model name'
cat: /proc/cpuinfo: No such file or directory
Правильнее все-таки наверное вот так:
$ uname -m
i386
replies: text: работает, но видимо не везде. uname -m выдаёт немного другую инфу (хотя тож обычно достаточную) LG.BALUKATION 19:38, 17 февраля 2008 (UTC)
thread_title:  ошибка в разделе "Определение порядка байтов" 

message: Считаю, что в текущем виде логичнее читается, если big-endian описать первым - из общего принципа, что сначала говорится об общем или более частом, потом о частностях. Основное что на это влияет - запись чисел людьми и массовость в сетевых протоколах - именно little-endian становится исключением и потому должно быть вторым (несмотря на x86).
В истории видна перестановка от AVB в обратном порядке, обоснования перестановки к ней не видно. Поэтому взял на себя смелость поменять порядок снова.
Netch 08:46, 18 декабря 2010 (UTC)
* В истории видна перестановка от AVB - в таких случаях неплохо бы приводить дифы, поскольку в этой правке с описание "порядок разделов" это относилось к служебным разделам (и разделу примечаний в частности). Иных перестановок разделов я не проводил и претензии ко мне необоснованны - в следующий раз следует внимательнее анализировать историю правок (в таком случае можно было бы увидеть, что такой порядок был заложен ещё самым первым автором). -- AVBtalk 14:00, 30 апреля 2012 (UTC) Кроме того, у меня замечание к формулировке: сначала говорится об общем или более частом, потом о частностях - простите, но в "споре тупоконечников и остроконечников" тупоконечники не являются "общим", а "остроконечники" - частным. Аргумент про большее распространение тоже следует подкреплять конкретикой. Потому что, к примеру, называть архитектуру x86 "менее распространённой" (чем что?) - это, мягко говоря, неосмотрительно. Если же отвлечься от подобных невалидных аргументов (про общее/частное и распространение), то порядок описания в данном случае - исключительно дело вкуса и стилистики. -- AVBtalk 14:10, 30 апреля 2012 (UTC)
thread_title:  Какой порядок описывать первым? 

message: Цитата:
В этом же виде (используя представление в десятичной системе счисления) записываются числа индийско-арабскими цифрами в письменностях с порядком знаков слева направо (латиница, кириллица).
То есть, порядок записи чисел 1, 2, 3, 4, 5 ... 10 (от малого к крупному) считается в этой статье "порядком от старшего к младшему"? Почему? Ведь записывается-то как раз от младшего к старшему, от нуля и вверх. А не от 10 и вниз.
* Имеется в виду не запись последовательности чисЕЛ, а порядок следования ЦИФР в чисЛЕ. -- AVBtalk 13:56, 30 апреля 2012 (UTC)
thread_title:  Порядок от старшего к младшему 

message: Отослал человека на википедию в ответ на его вопрос о том "какой байт старший?". Он прочитал статью о порядке байт, о байте и о битах, но не нашел ответ, хотя человек он неглупый.
Итак, давая определение порядку байт, статья оперирует терминами старшего и младшего байта, но не даёт ссылку на эти термины(нет такой статьи) и не разъясняет какой байт в слове считать старшим.
vSLY 15:31, 21 ноября 2012 (UTC)
replies: text: Старший байт содержит старшие биты, младший байт содержит младшие биты. — Monedula 17:20, 21 ноября 2012 (UTC)

text: * Или, немного попроще - старший байт содержит старшие разряды (цифры) числа, младший - младшие разряды. -- AVBtalk 23:46, 21 ноября 2012 (UTC)

text: Добавил разъяснение. --SergV 05:07, 22 ноября 2012 (UTC)
thread_title:  Старший/Младший байт 

message: В статье написано (обращаем внимание на фразу "(U+FFFE) не существует и не допускается)":
Одним из способов обозначения порядка байтов в юникодовых текстах является постановка в начале специального символа BOM (byte order mark, U+FEFF) — «перевёрнутый» вариант этого символа (U+FFFE) не существует и не допускается в текстах.
А теперь открываем статью про BOM http://ru.wikipedia.org/wiki/Byte_order_mark и смотрим раздел Представление кодировки byte order marks. В таблице одинаково фигурируют и FEFF и FFFE. Кто-то явно запустил в данную статью неверную информацию. Или неграмотное объяснение. Насколько я смог найти, нигде не запрещается FFFE, сплошь и рядом используется. 
replies: text: Последовательность байт FF+FE — это не то же самое, что юникодовский символ FFFE. В кодировке UTF-16LE последовательность FF+FE обозначает символ FEFF, а не FFFE. — Monedula 06:51, 18 января 2013 (UTC)
thread_title:  Метка BOM 

message: В таблице с числом 0xA1B2C3D4 в разделе "пример", кажется, напутано в строке "представление". Точно ли все числа в шестандцатиричном представлении? Если да, почему в одних используется префикс 0x, а в других нет?
thread_title:  Путанная запись 

message: В статье написано, что процессоры SPARC используют порядок байт от старшего к младшему (big-endian). Это утверждение, насколько я понял из разных источников, не совсем верно. Да, в архитектуре SPARC изначально был принят порядок big-endian и все ранние процессоры SPARC поддерживали именно его (они были тогда 32-разрядными), однако в конце 1990-ых годов появились 64-разрядные версии процессоров SPARC и вышел стандарт SPARC v9, описывавший 64-разрядную архитектуру. Так вот 64-разрядные SPARC'и согласно стандарту SPARC v9 стали поддерживать и прямой, и обратный порядок хранения чисел. Т. е. все SPARC'и, начиная с конца 1990-ых годов и по наши дни, используют 64-разрядные целые числа и работают как с форматом чисел big-endian, так и с форматом little-endian (по-русски, порядок от старшего к младшему и от младшего к старшему). Переход от одного формата к другому осуществляется переключением режима работы процессора (как переключить процессор из одного режима в другой, я правда не знаю). Т. е. современный SPARC - bi-endian. Так во всяком случае вроде бы пишут все источники, смотри в той же Википедии:
[]
[]
[]
Хотя похоже всё-таки, что родной для SPARC, даже для современных его моделей, является всё же форма представления чисел big-endian. Этот факт нужно уточнить и, если это действительно так, подчеркнуть в статье. Но формально, позволяя свободно работать с обоими представлениями, архитектура SPARC v9 (но не v8!) является bi-endian.
По этой причине просил бы авторов статьи разобраться с вопросом и исправить статью, сообщив правильную информацию о процессоре SPARC.
 217.10.40.176 10:46, 2 декабря 2016 (UTC)
replies: text: Просто копировать текст на основную страницу не хорошо, в статье стилистика другая. И ссылаться на англовики нельзя, это не ВП:АИ. В остальном, ВП:ПС .--SEA99 (обс.) 08:26, 3 декабря 2016 (UTC)
thread_title:  Процессор SPARC v9 относится скорее к bi-endian процессорам, чем к big-endian