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

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

Страницы: 148 49 50 5159 Следующая »
#720
(Правка: 9:35) 9:32, 6 янв. 2020

Panzerschrek[CN]
> И как же это работало? Таскали вместе сегментый регистр и сам указатель?
Да.
Определённая доля UB в плюсах, кстати, как раз связана с тем, что void* может оказаться парой сегмент:смещение, и хер его знает что произойдёт при переполнении смещения в ходе указательной арифметики.

Panzerschrek[CN]
> Качественная разница между 64кб и 4гб больше, чем между 4гб и дохреналиардом
> гб.
> На 64кб нельзя реализовать Crysis, на 4гб можно. А вот Crysis на более чем 4гб
> получится только немного лучше, чем Crysis на 4гб.
На той же CellOS специально приняли решение, чтобы адресное пространство процесса было 32-битным, хотя сам процессор самый настоящий 64-битный. Мотивация заключалась в том, что профит от убер-пространства для третьеплоечных игорей - практически никакой, а вот лишние 4 байта на каждый указатель в сумме расходуют нехилую долю RAM.


#721
(Правка: 10:06) 10:05, 6 янв. 2020

Panzerschrek[CN]
> И как же это работало? Таскали вместе сегментый регистр и сам указатель?

Конечно.
На x86 вообще было цинично - шина адреса 20 бит и могла бы влезть в 3 байта, но из-за специфичной сегментации сегмент+адрес длинного указателя надо было хранить в 4 байтах как будто адресное пространство 32-битное, но он им не было.
Имхо 16-битные процессоры с сегментацией вообще ошибка и как выше упоминали когда Motorola захотела сделать 16-битный процессор она просто взяла и сделала 32-битный процессор в котором 16-битность была только у АЛУ и вообще в системе команд никак не отсвечивала.
Так что Motorola 68k - правильный 16-битный процессор с шестнадцатью 32-битными регистрами общего назначения!
Ну или другой вариант - когда 16-битный процессор 16-битен во всём и имеет 16-битную адресную шину. Тоже нормально.

#722
10:13, 6 янв. 2020

Panzerschrek[CN]
> И как же это работало? Таскали вместе сегментый регистр и сам указатель?

компилятор разруливал

#723
10:14, 6 янв. 2020

=A=L=X=
> мхо 16-битные процессоры с сегментацией вообще ошибка

да ты знаток как делать лучше

#724
(Правка: 10:51) 10:50, 6 янв. 2020

=A=L=X=
> Имхо 16-битные процессоры с сегментацией вообще ошибка
Сегментация исполняла ту роль, что сейчас делает виртуальная память; а ещё она обратно совместима с простой 16-битной адресацией - ОС загружает себя как ей удобно, ставит сегменты где свободно и запускает программу. Если она старая - она работает как и раньше, не нужно ничего перекомпилировать и ништяк. Если она новая - она получает бонусную RAM, тоже ништяк. И при всём при этом новая архитектура оказывается чистым надмножеством старой - значит, в самом процессоре не нужно городить режимы и виртуализации, и инженеры получают свой ништяк.
А вот уже потом, с развитием технологий, стало возможно и настоящий контроллер памяти приклеить, и по нескольку фронт-эндов на один процессор размножать, и даже поддерживать гипервизора в юзерспейсе, чтобы запускать линукс в матрице, и дос в окошке, и при этом x64-хост продолжал прекрасно функционировать вместе со своим кернелом.

#725
(Правка: 11:00) 10:59, 6 янв. 2020

Delfigamer
> И при всём при этом новая архитектура оказывается чистым надмножеством старой -
> значит, в самом процессоре не нужно городить режимы и виртуализации, и инженеры
> получают свой ништяк.

В случае x86 не было никакой предыдущей архитектуры с которой нужно было бы поддерживать совместимость. Она сразу была сделана ради сегментации и с ней в самом сердце своём.
Хотя можно натолкнуться на утверждения, что там на уровне ассемблерных кодов можно было добиться совместимости с i8080 но разве есть где то ассемблер могущий код с i8080 превратить в валидный код для i8086? Никогда о таком не слышал.

#726
11:09, 6 янв. 2020

innuendo
> да ты знаток как делать лучше

Имхо в C/C++ надо было реально не тянуть яйца за хвост кота, а просто постулировать что могут быть архитектуры не соблюдающие стандарт с plain указателями и нормальной арифметикой всего что угодно и это тупо их проблемы. Тупые проблемы тупых архитектур.
И C/C++ сразу стал бы лучше и красивее. А вся эта срань с FAR/не FAR и моделями памяти стала бы отстоем и вещью ненужной гораздо раньше чем это случилось в реале.

#727
11:21, 6 янв. 2020

=A=L=X=
> Имхо в C/C++ надо было реально не тянуть

причём тут C++ ? тогда для x86 на асм писали в основном

#728
11:32, 6 янв. 2020

innuendo
> причём тут C++ ? тогда для x86 на асм писали в основном
Delfigamer
> Определённая доля UB в плюсах, кстати, как раз связана с тем, что void* может
> оказаться парой сегмент:смещение, и хер его знает что произойдёт при
> переполнении смещения в ходе указательной арифметики.

#729
11:58, 6 янв. 2020

=A=L=X=

разговоры в пользу бедных

#730
12:11, 6 янв. 2020

=A=L=X=
> В случае x86 не было никакой предыдущей архитектуры с которой нужно было бы
> поддерживать совместимость. Она сразу была сделана ради сегментации и с ней в
> самом сердце своём.

нужно было сразу делать RISC 32 битный да

#731
12:19, 6 янв. 2020

innuendo
> нужно было сразу делать RISC 32 битный да

Ты смеешься сам над собой?
Motorola 68k - первый 16-битный CISC-процессор который был 32-битным, но был 16-битным.
Назло тебе видимо, да?

#732
12:23, 6 янв. 2020

=A=L=X=
> Ты смеешься сам над собой?

посмейся сам - risc проще на кристалле быстрее - единственный минус памяти сразу больше нужно
что там внутри нынешних x64?

#733
(Правка: 12:31) 12:30, 6 янв. 2020

innuendo
> посмейся сам
Я конечно смеюсь, т.к. такая фирма как Motorola сделала 16-битный процессор назло тебе 32-битным.
Видимо.
Нет конечно.
Просто это ты не понял.
Реальный 16-битный процессор на 32-битной архитектуре просто назло одному русскоязычному хейтеру...
Нет, просто хейтер обосрался.

#734
13:04, 6 янв. 2020

=A=L=X=

я тебе рассказываю как можно было сделать лучше с самого начала но тебе не понять

Страницы: 148 49 50 5159 Следующая »
ФлеймФорумЖелезо