Войти
ФлеймФорумЖелезо

Блеск и нищета 8/16-битных консолей и ПК (105 стр)

Страницы: 1104 105 106 107 108 Следующая »
#1560
(Правка: 23:43) 23:41, 11 апр. 2021

}:+()___ [Smile]
> Естественно байт со смещением 0 брать с весом 256⁰, байт со смещением 1 — с
> весом 256¹ и т. д.
Довольнo спорно:

for(i = 0; i < n; ++ i)
    data = (data << 8) | buffer[i];
for(i = 0; i < n; ++ i)
    data = data | (buffer[i] << (i << 3));
Первое - легче реализуется алгоритмически и аппаратно: Цепочка регистров последовательной стековой загрузки.
Тогда как второе имеет очень много сдвигов в алгоритме, а аппаратно требуется демультиплексор для селекции отдельного регистра…

Или же всё таки докажите, что я глубоко заблуждаюсь? :))


#1561
(Правка: 0:03) 0:02, 12 апр. 2021

Alikberov
Попробуй длинное сложение двух чисел разной длины.

#1562
(Правка: 0:22) 0:16, 12 апр. 2021

Delfigamer
> Попробуй длинное сложение двух чисел разной длины.
A если и деление вспомнить - будем в пинг-понг играть? ;)
(Это в том смысле, что для сложения - удобно второе, для деления - первое. Аппаратно пинг-понгом схемы будут строиться в зависимости от задачи узла и здесь конкретный внешний порядок следования байтов как-то уже теряет смысл…)

Но…
Лично меня всегда напрягало (и напрягает), что в машинном коде вывести дробную часть числа последовательным умножением на 10 легче в консоль, чем целую!
Так как целую приходится размещать в буфере и заполнять его в обратном порядке.
(Нет, конечно, можно тупо начинать с больших степеней, используя таблицы…)

#1563
12:47, 12 апр. 2021

Alikberov
> Первое - легче реализуется алгоритмически и аппаратно
В железе регистры обычно не грузятся по частям. Наоборот, в современных процессорах кеш-линия больше регистра, даже векторного. А если величина больше регистра, то она грузится в несколько регистров и отличий между способами нет. Более того, раз все big-endian архитектуры вымерли, несмотря на неудобство для человеков, то это как раз свидетельствует в пользу более эффективной железной реализации.

> Лично меня всегда напрягало (и напрягает), что в машинном коде вывести дробную часть числа последовательным умножением на 10 легче в консоль, чем целую!
Выводить дробную часть умножением на 10, вообще говоря, неправильно.

> Так как целую приходится размещать в буфере и заполнять его в обратном порядке.
Это связано с тем, что человеки при записи чисел используют уродский big-endian.
Т. е. это классическая проблема legacy-совместимости, а не реальная математическая проблема.

#1564
13:29, 12 апр. 2021

}:+()___ [Smile]
> Т. е. это классическая проблема legacy-совместимости

Но вот что интересно насчет big-endian легаси - римские цифры были раньше арабских, и они хоть и не являются полностью позиционными, тем не менее за исключением цифр "на вычет" там тоже порядок big-endian. Не означает ли это, что "сначала бОльшая часть величины, а потом ее более мелкие детали" является более натуральным для человеческого мышления? Интересно было бы сравнить еще с какими-либо, скажем, с вавилонскими или с майянскими.

#1565
(Правка: 14:06) 14:03, 12 апр. 2021

Dmitry_Milk

Совсем недавно узнал про первое документально известное имя в известной истории и заодно первую математическую ошибку:
Тут немного на русском, но без подробных объяснений: https://pikabu.ru/story/kushim__pervoe_zapisannoe_imya_6787831
Вот тут немного на английском: https://en.wikipedia.org/wiki/Kushim_(Uruk_Period)
А вот собственно видео довольно подробно описывающая и то какая система исчисления используется: https://www.youtube.com/watch?v=MZVs6wF7nC4
Неизвестно как точно звучит древнешумерский язык и произносится ли это имя как "Кушим" и было ли это вообще именем или названием должности.
Историки восстанавливали звучание через близкородственный аккадский язык.
Кушим заведовал пивоварней и вёл отчётность на глиняных табличках.
Система исчисления тогда была конечно забавной и изображаемые сущности влияли на вид цифр:
Изображение
Здесь изображены "цифрами" некие меры объёма - они выглядят как кувшины  в разных позициях. Предположительно это что-то около пяти вроде литров.
Но еще были пять других систем изображений для других систем измерений.
Тут вроде как изображено поступление зерна в мерах объёма - подрисован символ ржи.
Кушим часто использовал именно меры объёма по понятным причинам - заезжали на производство зерно и всякий солод и выезжало пиво. И во внушительных количествах!

Прямое изображение чаши равно 1.
Повёрнутое на бок маленькое - 5 предыдущих.
Одиночная маленькая точка - 6 раз предыдущее.
Большая точка - 10 раз предыдущих.
Большая повёрнутая на бок чаша - три раза предыдущее.
И чаша с точкой внутри - 10 раз предыдущее и равно 9000 численно.

Так вот если теперь приглядеться к табличке выше, то действительно бОльшие знаки имеют тенденцию стоять правее.
Кушим записывал на одной стороне таблички какие то промежуточные записи (возможно за день или неделю), а потом выписывал на обратную сторону сумму всех граф.
Так вот забавно, но на одной табличке он явно пропустил три мелких точки и совершил ошибку в сумме что делает эту таблицу первой известной математико-бухгалтерской ошибкой в истории.

#1566
14:30, 12 апр. 2021

=A=L=X=
> Так вот если теперь приглядеться к табличке выше, то действительно бОльшие
> знаки имеют тенденцию стоять правее

Теперь осталось узнать, было ли в той письменности преимущественное направление письма (слева направо, справа налево, перемежающееся направление), и если было - то какое?

Потому что у тех же арабов хоть более "мелкие" цифры и стояли правее, фактически это было little-endian из-за направления письменности "справа налево".

#1567
(Правка: 14:34) 14:31, 12 апр. 2021

у китайцев(и использовавших их систему корейцев/японцев) - тоже
у вавилонян и майа("длинный" календарный счет - условно, т.к порядок чтения текста у них своеобразен. а обычный - непозиционный) бигендиан.

тут кстати небольшое отклонение - обе системы использовали "составную" разрядную систему. вавилоняне шестидесятиричную записывая сначала десятки потом единицы разряда. а майа двадцетиричную, записывая сначала единицы потом пятерки.

но воопше какое отношение "натуральность" для человека имеет к электронике?

#1568
14:37, 12 апр. 2021

Denadan
> но воопше какое отношение "натуральность" для человека имеет к электронике?

Никакого. Для электроники little-endian позволяет строить более простые схемы, использующие последовательную обработку. Для параллельной вроде бы пофиг, little или big.

#1569
(Правка: 15:29) 15:20, 12 апр. 2021

}:+()___ [Smile]
> Более того, раз все big-endian архитектуры вымерли

Этот порядок является стандартным для протоколов TCP/IP, он используется в заголовках пакетов данных и во многих протоколах более высокого уровня, разработанных для использования поверх TCP/IP. Поэтому порядок байтов от старшего к младшему часто называют «сетевым порядком байтов» (англ. network byte order). Этот порядок байтов используется процессорами IBM 360/370/390, SPARC, Motorola 68000 (отсюда третье название — порядок байтов Motorola, англ. Motorola byte order).
Порядок байтов от старшего к младшему применяется также во многих форматах файлов — например, PNG, FLV, EBML, JPEG.
> Выводить дробную часть умножением на 10, вообще говоря, неправильно.
Дo определённой степени у меня это получалось. Но на некоторых комбинациях выдаётся бесконечное число знаков и явное отклонение.
С этим я так и не смог справиться в рамках i8080…

Готовые алгоритмы используют память. Тогда как я решил умножение/деление производить в обход памяти - в РОН. Сложно, но можно. И как бы получилось…

+ Пример 24-битного делителя
(24 бита под мантиссу мне бы хватило с лихвой в моём Бейсике, так как весь набор Бейсиков использует 16 бит.)

Но, подпрограмма «PRINT_INT24» работает, а вот «PRINT_FRAC24» после десятичной точки выдаёт иногда мусор. То есть, вроде и работает, но порою ахинею выводит. Как я понял, из-за ошибки округления, так как этот механизм я не предусмотрел и не придумал, используя тупое умножение на 10.

+ Множилка на 10

Писал код полностью с потолка, не заглядывая в справочники, так, как умею и понимаю. Оказалось, проблему с округлением дробных знаков я не понимаю…

#1570
15:39, 12 апр. 2021

Dmitry_Milk
> Теперь осталось узнать, было ли в той письменности преимущественное направление
> письма

Да, верно. Но я что-то нахрапом не могу понять. Судя по видео таблички у Кушима были упорядочены в столбцы. На вики написано что когда шумеры писали столбцами они писали столбцы справа-налево. Но судя по виду табличек похоже что слева-направо. Хм, не знаю даже тогда.

#1571
(Правка: 16:57) 16:56, 12 апр. 2021

Alikberov
> Первое - легче реализуется алгоритмически и аппаратно: Цепочка регистров
> последовательной стековой загрузки.
> Тогда как второе имеет очень много сдвигов в алгоритме, а аппаратно требуется
> демультиплексор для селекции отдельного регистра…

Открою правду.  Регистры аппаратуры, если их разрядность больше 8 бит, в большинстве случаев требуют записи именно в Big-Endian, несмотря на то, что ядро CPU Little-Endian.  Особенно этот геморой с байт-своппингом вылезает, если используется DMA для пересылки.  И хорошо, если в настройках DMA можно менять порядок байт при передаче.  Хуже, когда нельзя: приходится весь буфер байт-своппить перед отправкой его через DMA.

P.S. Иногда попадаются  девайсы, в настройках которых можно указать порядок байт при записи в регистры. Такое у меня в почёте )))

#1572
(Правка: 20:10) 20:00, 19 апр. 2021

Немногo по теме…

Итак…
Все Спектрумисты борятся с проблемой клэшинга.
И в РАДИО-86РК он имеется, так как непосредственной графики в нём нет, но есть 16 символов псевдографики:

КодСимвол
01₁₆
02₁₆
03₁₆
04₁₆
05₁₆
06₁₆
07₁₆
10₁₆
11₁₆
12₁₆
13₁₆
14₁₆
15₁₆
16₁₆
17₁₆
Спектрумисты сразу узнают эти символы, так как 8 из них входят в набор знакогенератора, а ещё восемь образуются инверсией.
Естественно, в РАДИО-86РК, из-за экономии на единственном элементе К155ЛП5 в узле формирования графики символов из ПЗУ знакогенератора, никакой инверсии нет. Потому и символы псевдографики уложены в нижний ряд управляющих кодов.
Не повезло и с символом «▜» с кодом 7, так как он используется в подпрограмме стандартного вывода на экран под «звонок» и отобразить его можно лишь непосредственной записью в буфер экрана, что снижает совместимость программ между 16 кб версиями и 32 кб, так как буфер экрана смещается на все 16 кб.

Естественно, все Бейсики имеют операторы PLOT и LINE для построения графики 128×50.
Если заглянуть в машинный код оператора LINE, можно обнаружить цикл с вызовами PLOT. Впрочем, у ZX-Spectrum так же.

Однако, я решил пойти иначе: Сделать PLOT частным случаем LINE: Онлайн-запуск
В начале выйдет «знак качества СССР», но тут же зарисуется линиями.
Если кликнуть по экрану, включится режим рисования линий.
Если дважды нажать на одно место, произойдёт очистка экрана.

Как можно видеть, скорость построения линий достаточно высока. Так как вместо рисования отдельным псевдо-пикселями, рисуется знакоместо сразу. Но символы перебираются в соответствии с счётчиком итерации.
Говоря по Spectrum'ски, графика рисуется блоками 8×8, но перебираются все возможные символы. То есть, как если бы графика рисовалась всегда текстом 32×24, но использовался бы набор из 2⁶⁴ символов.

Потому, Вы можете в моём алгоритме видеть артефакты в линиях под определёнными углами: Некоторые рисуются просто идеально, а на остальные - смотреть больно.
(Кликните по экрану мышкой дважды, а потом, не отпуская ЛКМ, посмотрите, как рисуются линии под разными углами. И обратите внимание на скорость: Иногда проявляется эффект наложения синхронизации.)

К сожалению, до ума я эту идею не довёл и подменить своим алгоритмом код в Бейсиках пока не могу.

Иными словами, просто сделал по примеру Брезенхэма:
Изображение
Ничего нового не изобретал. Просто, так как квантование знакоместа псевдографикой у РАДИО-86РК - 2×2, то воспользовался такой вот оптимизацией.

То есть, если основная ось - X, то используются символы «▀», «▚» и «▄».
Пример линии:

▀▀▀▚▄▄▄
       ▀▀▀▄▄▄

P.S.: А где найти для ZX-Spectrum подобные открытые алгоритмы?

#1573
(Правка: 20:05) 20:04, 19 апр. 2021

Интересная DIY тематика на авторском сайте.
http://cowlark.com/

P.S. Fuzzix проект Unix7 для RPi

#1574
20:39, 19 апр. 2021

Alikberov

http://zxdn.narod.ru/coding/adv7fsln.htm  отсюда http://zxdn.narod.ru/coding.htm#graphic

Страницы: 1104 105 106 107 108 Следующая »
ФлеймФорумЖелезо