Просмотр полной версии : Про Motorola, IBM, DEC, ...
В ветке про УКНЦ и ДВК возникла тема и про другие системы. Решил вынести её в отдельный тред.
Интересно, что по скорости 1801ВМ2 и 1801ВМ3 соотносятся друг к другу примерно как и мотороловские 68020 и 68030 - ещё одна неожиданная связь между этими архитектурами. Могу предположить, что если бы мотороловцы более последовательно заимствовали архитектуру DEC и не переворачивали подобно мейнфреймам IBM порядка байт, то у них дела пошли бы лучше. А так получилась наглядная иллюстрация к пословицам про двух непойманных зайцев или два неотсиженных стула.
Да это как посмотреть, одним так удобно, другим иначе.
В 32-разрядной архитектуре того времени разницы немного, но мотороловцы тупо её копировали даже на свои 8-битные процессоры, где BE являлась заметным тормозом в операциях сложения и вычитания. В их лучшем процессоре 68000 этот тормоз заметить сложнее, но он там тоже есть в этих же операциях.
680х0 не состоялись потому, что миру оказались не нужны два различных микропроцессора для компьютеров, а конкуренцию с i386 они не выдержали по вполне понятным причинам - писюк победил всех конкурентов. Интеля, кстати, тоже облажались - когда назрел переход на 64 разряда, могли бы подсуетиться и предложить свой IA-64, всего-то и делов, что доработать этому IA-64 совместимость с i386, так нет, дождались, что AMD предложили свой 64-разрядный вариант, и он стал основным. И все. Пройдет еще 5-10 лет и архитектура IA-64 будет забыта так же, как и 860х0 и iAPX432.
Могу вам указать человека, который с первой половины 80-х возможно только из личного энтузиазма много пиарил 68000 и от которого пошло мнение, близкое к Вашему, - http://suddendisruption.blogspot.com/2007/10/booting-sage-computer-subjective_5926.html - этот человек сделал реально очень хороший компьютер - https://en.wikipedia.org/wiki/SAGE_Computer_Technology - благодаря, которому, в частности, появилась знаменитая Амига. Но этот компьютер хотя и был раза в 3 быстрее первых РС, но появился на год позже, не имел графики, не мог использовать сопроцессор или виртуальную память, был дороже. Появление 80286 и провал мотороловцев с 68020 и 68030, особенно заметный после появления 80386 и ARM, заставили производителей компьютеров искать альтернативу 68к. Sun начала делать свои Спарки, Silicon Graphic - MIPS, а сама Моторола вместе Аплом и Айбиэмом перешла на PowerPC. Кстати, сам Род, хотя так и не отказался от веры в 68000 своих лучших лет, но в новом поколении компьютеров Sage - Stride стал использовать что-то другое, а что, так и не смог найти - какое-то VME.
Конечно, 68000 был в целом получше 8086. Но было немало "но", вот некоторые:
1) не было дешёвого 8-битного варианта, 68008 появился только в 1982 и был почти в два раза медленнее. Для сравнения 8088 только процентов на 30% медленнее 8086 из-за очереди команд;
2) персональные системы на 68000 стали доступны по ценам широким массам потребителей не ранее 1983-84. Системы на 68000 стали массовыми только с 1986 (Атари 520СТ), 1987 (Амига-500). Системы Unix для среднего уровня были популярны с первой половины 80-х, но это уже не для масс, а для пусть и небольших, но организаций - РС в этом секторе действовали на порядки успешнее;
3) 68000 не мог работать с виртуальной памятью - для этого требовался ещё один процессор (например, сам 68000 или z80);
4) для 68000 не было мат. сопроцессора - для 8086/8088 был;
5) на задачах обработки байтовой информации (текста) 8086 мог обгонять 68000 на той же частоте.
И причем тут РС? Аплы 2 отлично шли, но задержка с появлением 65816 до 1983, а затем нежелание создавать конкуренцию Макинтошам, закрыли эту серию. Сами Макинтоши также вполне уверенно конкурировали с РС и только провал Моторолы с процессорами создали для них большие проблемы. А были ещё вполне успешные Амиги и Атари СТ. Реальный пример провала мотороловцев: дешевая 32-битная Амига-1200 появилась только в конце 1992 с 68020 на 14 МГц, когда пользователи могли за меньшую цену взять ПК с 80386 на 25-33 МГц с 1991. Архимедам не хватило финансовых ресурсов для выхода на мировые рынки и в Акорн решили ими пожертвовать для продвижения АРМа и пойти на сделку с Апл. PowerPC также были во вполне успешных ПК и только отставание от Интел к середине нулевых заставило Апл перейти на х86.
Отвечаю по пунктам.
1. 8-битный вариант, в общем-то, и не особенно был нужен. Где-то в сети бродило фото IBM-овского терминала для их мэнфреймов на процессоре 8085, который после небольшой переделки и стал первым писюком. То есть, Межделмаш сделал этот писюк "на от...вали", не прикладывая к этому особых усилий. Что неудивительно: руководство IBM искренне считало, что ПК - это модная игрушка, мода пройдет, а мэйнфреймы были, есть и будут! Поэтому его не стали и патентовать - напротив, выложили всё, клонируй, кто хочешь! Хорощо, хоть поставили туда 16-разоядный 8088, который, как раз, и был сделан для прямой замены 8085. Мы уже прикидывали: поставь туда 68000, машинка была бы баксов на 500-700 дороже. Ну и что? Весь мир ждал, какую персоналку предложит IBM? Было множество народу, кто заплатил бы и дороже; клонмейкеры стояли на низком старте... Это не досужие измышления, я тогда (в 80-м) регулярно читал журнал "Электроника" (перевод американского "Electronics"), атмосфера в отношении ПК была именно такая.
2. Большое количество клонов IBM PC и высокая конкуренция среди клонмейкеров стимулировали увеличение производства компонентов для IBM PC и снижение цен на них. Спрос на Мотороллеры был существенно меньше, соответственно и наращивать производство и разрабатывать новинки Моторола не особенно торопилась. И это запаздывание на 2 года на старте привело к тому, что гонку выиграть не удалось.
3. 8088 и 8086 тоже не могли работать с виртуальной памятью. И, вроде-бы, 80186 тоже не мог.
4. Опять же, не было спроса.
5. Сложный вопрос - мог обгонять, мог не обгонять, да и частота для CISC - понятие растяжимое...
Сами Макинтоши также вполне уверенно конкурировали с РС Ага. В Штатах. А во всем мире из 10 ПК 9 были писюками и 1 Маком.
PowerPC также были во вполне успешных ПК и только отставание от Интел к середине нулевых заставило Апл перейти на х86.Так о чем я и говорю: все компьютерные архитектуры, кроме х86/АМД64 бесперспективны. Так же, как и все мобильные, кроме АРМ.
Lethargeek
24.01.2020, 15:47
1) не было дешёвого 8-битного варианта, 68008 появился только в 1982 и был почти в два раза медленнее.
притом, что и "полноценный" 68000 довольно нетороплив
3. 8088 и 8086 тоже не могли работать с виртуальной памятью. И, вроде-бы, 80186 тоже не мог.
...а 80286 - "лучше бы не мог" :D
Многие компромисы от х86 неплохо бы вписались в архитектуру DEC (например обращение к половинкам регистров, сегментные регистры.. не говоря о всяких цикличных плюшках и PUSHA POPA)
Отвечаю по пунктам.
1. 8-битный вариант, в общем-то, и не особенно был нужен. Где-то в сети бродило фото IBM-овского терминала для их мэнфреймов на процессоре 8085, который после небольшой переделки и стал первым писюком. То есть, Межделмаш сделал этот писюк "на от...вали", не прикладывая к этому особых усилий. Что неудивительно: руководство IBM искренне считало, что ПК - это модная игрушка, мода пройдет, а мэйнфреймы были, есть и будут! Поэтому его не стали и патентовать - напротив, выложили всё, клонируй, кто хочешь! Хорощо, хоть поставили туда 16-разоядный 8088, который, как раз, и был сделан для прямой замены 8085. Мы уже прикидывали: поставь туда 68000, машинка была бы баксов на 500-700 дороже. Ну и что? Весь мир ждал, какую персоналку предложит IBM? Было множество народу, кто заплатил бы и дороже; клонмейкеры стояли на низком старте... Это не досужие измышления, я тогда (в 80-м) регулярно читал журнал "Электроника" (перевод американского "Electronics"), атмосфера в отношении ПК была именно такая.
2. Большое количество клонов IBM PC и высокая конкуренция среди клонмейкеров стимулировали увеличение производства компонентов для IBM PC и снижение цен на них. Спрос на Мотороллеры был существенно меньше, соответственно и наращивать производство и разрабатывать новинки Моторола не особенно торопилась. И это запаздывание на 2 года на старте привело к тому, что гонку выиграть не удалось.
3. 8088 и 8086 тоже не могли работать с виртуальной памятью. И, вроде-бы, 80186 тоже не мог.
4. Опять же, не было спроса.
5. Сложный вопрос - мог обгонять, мог не обгонять, да и частота для CISC - понятие растяжимое...
Ага. В Штатах. А во всем мире из 10 ПК 9 были писюками и 1 Маком.
Так о чем я и говорю: все компьютерные архитектуры, кроме х86/АМД64 бесперспективны. Так же, как и все мобильные, кроме АРМ.
По пунктам на пункты. :)
1. Однако, рынок 8-биток был очень прибыльным до конца 80-х, хороший пример этому - Амстрады. 16-битники стали заходить в массы только со второй половины 80-х. Поэтому доступность IBM PC по цене была существенным плюсом. Повторю, машин по сходным ценам на 68000 не было до середины 80-х. 8085 в терминале - что тут необычного, его и делали как перефирийный процессор в частности для терминалов. Он хорошо пошёл с VT102 и другими. IBM использовало его в своём предписи от 1981 Data Center - весьма солидный компик - они его и поддерживали несколько лет, но память дешевела и использовать банкование стало несолидно. Считаю, что первый ПК сделали всё-таки в Ванге, в году 72. Потом IBM сделало что-то в чемодане - похоже на ПК - они его так и называют сейчас. И только потом возник Возняк. Апл сделало Лизу в 1982 на 68000 - получился динозавр за $10000 - не пошло. Дешевле не получалось - дешёвая электроника была тогда ещё 8-битная. Если бы IBM сделали плохой ПК - он бы не пошёл, у них было полно провалов, начиная с PCjr и PS/2. PC получился отличный, а открытая архитектура дала этой архитектуре неожиданные возможности. Что там IBM считало - штука тёмная - всё-таки эта огромная корпорация с огромными возможностями и резервами. Знаете наверное, что главный конструктор IBM PC странно погиб вскоре после успеха своих ПК? Фактически IBM сыграла на Интел, но Интел реально предлагала лучшие и оригинальные процессоры для своего времени. А Моторола постоянно склонялись к копированию, в частности, DEC - архитектуры начала 70-х.
2. О том и речь. Отстали. Сначала было слишком дорого, а потом Интел сделала 80286 и писи пошли массами.
3. Тут непростой вопрос. Сегментая память даёт пусть и неполноценное, но какой-то управление памятью. Архитектура DEC PDP11 и предполагала сегменты по 64К. Это позволяет сравнительно просто перенести на 8088 Unix при ограничении 64К на процесс. Было довольно много систем на 8088/86 под варианты Юникса, но они не стали массовыми.
4. Не понял. Для графики (3Д вообще немыслима без сопра) и многих бизнес-приложений сопёр штука необходимая. Это очень серьёзный минус для офисного ПК.
5. Посмотрите как 68000 работает с байтами и всё станет ясно.
До начала 90-х было много разных ПК. Макинтоши стали отставать по быстродействию из-за тормознутости 68к с середины 80-х, а PowerPC появился уже только к середине 90-х. Было потеряно более 5 лет - за это время клоны РС заняли очень крепкие позиции. АРМ, конечно, был крут, но завязли в сложностях мировых рынков - очередной раз Америка побила британцев с их вроде бы лучшими позициями.
притом, что и "полноценный" 68000 довольно нетороплив
...а 80286 - "лучше бы не мог" :D
Всё ж заметно побыстрее 8088 и 8086 - компьютеры Sage тому пример. Кстати, в Амиге 500 процессор использует только половину тактов, т.е. реально работает на 3.5 МГц, остальное шло на видео. Поддержку быстрой памяти добавили только в А1200, но саму быструю память надо было покупать отдельно. В PC вся память всегда была быстрой.
Это вы повторяете Билла Гейтса. Типа не для ДОС. Но с 80286 на PC пошёл полноценный Юникс - Зиникс - это тогда много значило.
- - - Добавлено - - -
Многие компромисы от х86 неплохо бы вписались в архитектуру DEC (например обращение к половинкам регистров, сегментные регистры.. не говоря о всяких цикличных плюшках и PUSHA POPA)
У вас в списке много бекашек - помогли бы с тестированием по пи-затвору. Пожалуйста. Было бы интересно сравнить разные БК, УКНЦ. А архитектура x86 вполне неплохая, у всех конкурентов кроме АРМ была похуже, но АРМ начали с чистого листа, а х86 тащили и тащат за собой совместимость.
Lethargeek
25.01.2020, 14:47
Это вы повторяете Билла Гейтса. Типа не для ДОС. Но с 80286 на PC пошёл полноценный Юникс - Зиникс - это тогда много значило.
зиниксы-шмузиниксы быстро кончились, а костыли с дебильными дескрипторами остались
- - - Добавлено - - -
А архитектура x86 вполне неплохая, у всех конкурентов кроме АРМ была похуже,
звучит как "инвалид наш был бодрячком, и костыли у него лучше всех других костылей" :D
blackmirror
25.01.2020, 14:56
Lethargeek, начиная с 386 можно спокойно делать плоскую модель памяти и забыть про сегменты. А что касается 286, кроме сегментов он не мог обратно в реальный режим вернуться, и от этого совместимость с досовскими программами страдала намного сильнее. Для OS/2 возврат в реальный режим пришлось делать через сброс и флаг в биосе что память чистить не нужно, а передать управление в OS/2.
Lethargeek
25.01.2020, 15:17
начиная с 386 можно спокойно делать плоскую модель памяти и забыть про сегменты.
да хоть с 486 - на формат дескрипторов спокойно даже просто смотреть нельзя :D
начиная с 386 можно спокойно делать плоскую модель памяти и забыть про сегменты.У 68000 ИЗНАЧАЛЬНО была плоская модель памяти. И изначально была возможность адресации до 16М. И система команд у него была очень "вкусная". Не хуже, чем у любимой PDP-11, писать под 68000 на асме - такое же удовольствие, как и под PDP-11. В отличие от мерзкого х86 - лично я так и не смог преодолеть рвотный барьер, отчего так и не научился программировать для писюка на асме.
3. Тут непростой вопрос. Сегментая память даёт пусть и неполноценное, но какой-то управление памятью.Которое на фиг не нужно при плоской модели памяти до 16М при потенциальных 4Г.
До начала 90-х было много разных ПК. Макинтоши стали отставать по быстродействию из-за тормознутости 68к с середины 80-х, а PowerPC появился уже только к середине 90-х. Было потеряно более 5 лет - за это время клоны РС заняли очень крепкие позиции Именно. Высокий спрос и высокая конкуренция в секторе писюков заставили всех участников производства наращивать выпуск и разрабатывать более скоростные машинки с бОльшим адресным пространством. А Маки пользовались спросом только в Штатах, и не одни они, писюков и в Штатах продавалось больше, чем Маков. И конкуренции никакой - надгрызенные яблоки все запатентовали наглухо, никаких клонмейкеров...
да хоть с 486 - на формат дескрипторов спокойно даже просто смотреть нельзяВот-вот Поубивал бы!..
У 68000 ИЗНАЧАЛЬНО была плоская модель памяти. И изначально была возможность адресации до 16М. И система команд у него была очень "вкусная". Не хуже, чем у любимой PDP-11, писать под 68000 на асме - такое же удовольствие, как и под PDP-11. В отличие от мерзкого х86 - лично я так и не смог преодолеть рвотный барьер, отчего так и не научился программировать для писюка на асме.
Которое на фиг не нужно при плоской модели памяти до 16М при потенциальных 4Г.
Именно. Высокий спрос и высокая конкуренция в секторе писюков заставили всех участников производства наращивать выпуск и разрабатывать более скоростные машинки с бОльшим адресным пространством. А Маки пользовались спросом только в Штатах, и не одни они, писюков и в Штатах продавалось больше, чем Маков. И конкуренции никакой - надгрызенные яблоки все запатентовали наглухо, никаких клонмейкеров...
Только очень крутая контора могла себе позволить более мегабайта до 1982, поэтому это преимущество (адресуемость 16 МБ) было чистой абстракцией. А отсутствие ММU делало невозможным запуск Юникса: в популярной Танди 16 для MMU использовали z80 - 68000 сам не мог. 8086 пусть и неидеально, но, используя сегменты, мог. Не путайте адресуемость и MMU - Линукс, Виндуз или любая нормальная ось очень много чего без MMU не может.
Открытая архитектура писи - это до сих пор тайна. Слово intel, кстати, означает разведкy. Из-за этой архитектуры писи пошли в большой тираж. А Род, который пытался делать также для 68000, оказался одиночкой. Но в любом случае, 68к стали отставать от х86, начиная с 80386. Задолго до того, как писи стало слишком много. Возможно, если бы 68020/30 были бы побыстрее и подешевле, то появилась бы и открытая архитектура под них. Но 68к стали тормозить и при этом были слишком дорогими для дешёвых массовых ПК.
Lethargeek
31.01.2020, 23:23
отсутствие ММU делало невозможным запуск Юникса: в популярной Танди 16 для MMU использовали z80 - 68000 сам не мог. 8086 пусть и неидеально, но, используя сегменты, мог
шта-шта мог? xenix запускать штоле? так его и 68k смог прекрасно в яблочной лизе и без помощи z80
(который и в танди не был необходим для хениха, а достался "по наследству", для совместимости)
Не путайте адресуемость и MMU
а тем более ущербные сегменты и mmu :v2_sick:
HardWareMan
01.02.2020, 08:48
У 68000 ИЗНАЧАЛЬНО была плоская модель памяти. И изначально была возможность адресации до 16М. И система команд у него была очень "вкусная". Не хуже, чем у любимой PDP-11, писать под 68000 на асме - такое же удовольствие, как и под PDP-11. В отличие от мерзкого х86 - лично я так и не смог преодолеть рвотный барьер, отчего так и не научился программировать для писюка на асме.
У меня обратный опыт. Начинал с MCS51, MCS80 и x86. Потом уже М68К. А уже потом - AVR и ARM. Никаких рефлексов, чётко понимаешь плюсы и минусы той или иной архитектуры. Может всё дело в вашей вере?
Не путайте адресуемость и MMU - Линукс, Виндуз или любая нормальная ось очень много чего без MMU не может.
Основная функция MMU это делать окружение каждой программы одиноковым с минимальными затратами физического ОЗУ. А это невозможно без сегментации. Т.е. основная проблема линейного сегмента памяти М68К такое же как и у i8080: это отсутствие возможности перемещать код в произвольное место. Z80 имеет костыль в виде 6 команд относительного перехода. А х86 сразу умел в сегменты и при компиляции адрес можно было не учитывать совсем (он полностью зависел от используемой системы, ибо именно она пилила каждый сегмент как ей хотелось). Вот и весь сказ. Сегменты выиграли из-за полностью перемещающегося кода. Это уже потом ввели функционал защиты, когда решили что программная многозадачность круче прерываний, которых, кстати, на всех и не хватит.
Слово intel, кстати, означает разведкy.
:v2_dizzy_facepalm: Разведка это intelligence, а intel это просто integrated electronics.
шта-шта мог? xenix запускать штоле? так его и 68k смог прекрасно в яблочной лизе и без помощи z80
(который и в танди не был необходим для хениха, а достался "по наследству", для совместимости)
а тем более ущербные сегменты и mmu :v2_sick:
У Лизы был MMU, потому там Зиникс и запускался. Этот MMU ругают, но пишут, что он был быстрым. Сегменты дают функциональность MMU для небольших (до 256 КБ) программ, естественно, без защиты и виртуализации памяти. Кстати, на некоторых PDP-11 можно было иметь отдельные сегменты данных и кодов, получая до 128 КБ на процесс, но х86 давал вдвое больше и даже в самом дешёвом варианте.
Общался с людьми, которые использовали Юникс с Танди. Они говорили, что без хотя и простенького MMU на базе z80 это было бы невозможно.
:v2_dizzy_facepalm: Разведка это intelligence, а intel это просто integrated electronics.
Тренируйте свой английский. Вот пример из словаря
information of military or political value.
"I need some intel, and I need it fast"
1960s: abbreviation of intelligence.
И сомневаюсь, что кто-то сомневается, что история с открытостью писи оказалась очень выгодной именно для Интел. Но сам тренд открытость возможно того и стоил - пошли всякие оупен-сорцы и т.п. Вот уже и железа есть немало открытого.
HardWareMan
01.02.2020, 12:40
Тренируйте свой английский. Вот пример из словаря
information of military or political value.
"I need some intel, and I need it fast"
1960s: abbreviation of intelligence.
Я знаю про использование сокращённой формы, но в данном контексте беседы intel имелся в виду очевидный крупный производитель полупроводниковых устройств, в частности процессоров. А их название это сокращение от указанного мной выше. И именно поэтому e немного смещена вниз, чтобы не триггерить людей с синдромом теории заговора. Хотя я не отрицаю того факта, что то, что мутировало из технологии AMT самый что ни есть откровенный бэкдор и шпион. Да, я про IntelME.
PS Интересно, а Даль вписывал в свой словарь всякие сокращения, усечения да аббревиатуры?
PPS Личный лингвист уточнил, что сокращение intel используется только в значение разведданные, это в противовес от разведка и интеллект, оба смысла которых означает полное слово.
MMU нужен в двух случаях:
- увеличение количества доступной памяти, когда из за архитектуры, промаха проектирования или привычки программистов писать раздутые программы памяти перестало хватать. Сегментные регистры 8086 - тот же MMU и попадают в эту категорию (16 битный адрес - это всего лишь 64 кб, а из за неудачной системы команд ещё и программы получались раздутыми)
- запуск нескольких процессов с возможностью защиты между процессами. При этом предполагается наличие в процессоре нескольких (как минимум двух) режимов работы разного уровня привилегированности, что бы обычные процессы не могли получить доступа к работе MMU. Очевидно, что в 8086 этого не было.
Возможность перемещать код в произвольное место - это, в первую очередь, возможность писать позиционно-независимый код. С крайне небольшими накладными расходами, на PDP-11 это возможно. Насколько это возможно на x86-x64, не могу сказать наверняка, но - известный факт - dll библиотеки в Windows линкуются с указанием базового адреса, при этом исходно Windows пытается отобразить загруженную библиотеку в адресное пространство процесса с этого же базового адреса и если это невозможно (в адресное пространство процесса уже отображена dll библиотека с этого же базового адреса) - windows по информации из dll библиотеки патчит код в памяти для работы с другого базового адреса. Не могу сказать, почему пошли таким путём в Windows, но могу предположить, что накладные расходы могли оказаться слишком большими или это вообще не возможно (на это намекает ещё тот факт, что, насколько мне не изменяет память, в x86-x64 нет относительных переходов на произвольное расстояние, в то время как в PDP-11 таких возможностей аж две - короткий переход - основной плюс - команда в одно слово и длинный переход). Так же не могу сказать, как обстоят дела с аналогом dll библиотек в unix-подобным системах.
Да, сегментные регистры, а точнее возможность префиксом для команды указать использование другого сегментного регистра - это интересная и в ряде сценариев удобная возможность, но - их роль в сценарии по умолчанию (то есть когда префикс не используется) достаточно узко специализированная и их не такое большое количество (в исходном 8086 всего 4, причём только 3 используется по умолчанию), при этом, если требуется использовать другой блок памяти - нужно всё равно явно грузить и уж ни о какой защите на изменение содержимого регистра речи не идёт.
Если посмотреть на модель MMU в PDP-11 - во первых их больше (7+1), во вторых они универсальны (и только в определённых моделях была реализована специализация, но при этом и количество регистров увеличилось до 15+1), в третьих - их легко защитить от неконтролируемой смены (и есть контролируемый ОС процесс изменения), так же, как и в 8086 есть необходимость явной загрузки. Ну и минусом можно записать, что для команды нельзя указать префиксом - какой регистр (регистры) будет(будут) использоваться.
- - - Добавлено - - -
Вдогонку. С M68k работать не приходилось, сказать ничего не могу, на ассемблере x86-x64 много писать не приходилось, но после удобной системы команд PDP-11 - считаю крайне не удобным. А также - тот же самый (по функционалу) код на PDP-11 получается гораздо короче - спасибо и системе команд и режимам адресации. В своё время для меня было до некоторой степени шоком, что такая ограниченная по возможностям и однозадачная система MS-DOS требовала для себя столько памяти, при том что первые версии были так же написаны на ассемблере. Это то же о чём то, но говорит.
blackmirror
01.02.2020, 14:25
в x86-x64 нет относительных переходов на произвольное расстояние
Условные переходы в x86 изначально были со смещением в байт, для перехода в пределах сегмента нужно было делать обход команды безусловного перехода по инверсному условию. Хотя при смещении размером в слово были и абсолютные и относительные формы переходов и вызовов подпрограмм. Для дальних переходов с перезагрузкой сегментного регистра адрес уже всегда абсолютный.
Начиная с 386 в систему команд добавили условные относительные переходы со смещением размером в слово, то есть сам код сделать позиционно-независимым легко. Проблема только в лежащих внутри него данных, поскольку единственный способ узнать текущий IP это call на команду pop.
Для x86-64 добавили режимы адресации позволяющие читать данные относительно IP, то есть там проблем с позиционно независимым кодом нет вообще, за исключением того, что смещение всего 4 байта и далее +-2Гб данные не достанешь. Кстати все арифметические команды с константами тоже принимают 4 байта, знаково или беззнаково их расширяя. Единственное что можно сделать с 8 байтной закодированной в команду константой, это загрузить её в регистр.
Lethargeek
01.02.2020, 15:21
Сегменты дают функциональность MMU для небольших (до 256 КБ) программ, естественно, без защиты и виртуализации памяти.
а вот здесь поподробнее, какую такую "функциональность mmu" без виртуализации и защиты (которые и есть основная функция mmu)?
и что за зверь такой "небольшая (до 256 кб) программа x86"? для меня, если сказано "программа" - значит, программный код
не скажу сейчас про хених, но в досе размер кода более 64кб требовал exe формата, чтобы патчить код при загрузке
(что, естественно, проделать можно на любом процессоре с любой осью)
Начиная с 386 в систему команд
Для x86-64
Это уже значительно более современные процы, к тому же 32 битные
Попробуйте сделать такое на 8086, который, как и PDP-11 - 16-ти битный.
Если продолжать развивать идеи PDP-11 на 32-битный вариант (VAX, с моей точки зрения - значительный отход от этих идей) - все узкие места из за 16-ти битности точно так можно исправить. И вот этот (гипотетический) проц можно будет сравнивать с 386 и далее процами. И он так же будет лучше по системе команд, ибо это заложено было изначально. А 386 и далее точно так же будет кривым. Такова цена совместимости.
Ещё плата за слишком запутанную систему команд - необходимость делать вертикальный микрокод, то есть по сути внутри проца интерпретатор.
Хотя с моей точки зрения - микрокод (как и синхронные схемы) в принципе ущербный подход, но это отдельная тема.
- - - Добавлено - - -
вот здесь поподробнее, какую такую "функциональность mmu"
4 сегментных регистра, если без их перезагрузки, и дают как раз 256 кб. Но строго говоря - 192 + 64. Примерный аналог - процы PDP-11 с поддержкой пространства данных - до 128 кб
- - - Добавлено - - -
о в досе размер кода более 64кб требовал exe формата, чтобы патчить код при загрузке
Сам формат com был ограничен 64 кб в принципе. .exe как раз обходит это ограничение. А нужно ли патчить или нет - это вопрос второй.
"функциональность mmu" без виртуализации и защиты (которые и есть основная функция mmu)?
Виртуализация и защита - одна из двух функциональностей mmu, но не обязательная. Хотя в PDP-11, скажем, присутствовали обе.
Lethargeek
01.02.2020, 16:03
4 сегментных регистра, если без их перезагрузки, и дают как раз 256 кб
они не дают "программу 256 кб" и без их перезагрузки на x86 толком ничего полезного не поделаешь (не намного больше, чем может com)
- - - Добавлено - - -
Виртуализация и защита - одна из двух функциональностей mmu, но не обязательная.
чсх, вновь туманные намёки на таинственную "остальную функциональность" вместо внятного и членораздельного описания))
они не дают "программу 256 кб" и без их перезагрузки на x86 толком ничего полезного не поделаешь
Сегмент кода, сегмент данных, сегмент стека, доп сегмент. Содержимое сегментного регистра - номер 16-ти байтного блока, то есть при вычислении реального адреса можно сказать, что его содержимое сдвигается на 4 бита влево и складывается с адресом из ip или команды.
Пусть CS=0, DS=1000, SS=2000, ES=3000. Тогда реальные адреса команд попадут в диапазон 0000-FFFF, данных - 10000-1FFFF, стека 20000-2FFFF, доп сегмента - 30000-3FFFF, итого общий объём - 00000-3FFFF или 256 кб. Но. Это не увеличит максимальный объём кода, данных или стека - всё равно останется по 64 кб, а доп регистр используется только на строковых командах, поэтому я и написал - 192+64. В целом - надо достаточно извратиться, что бы по полной использовать эти 256 кб без перезагрузки регистров, но технически это возможно.
чсх, вновь туманные намёки на таинственную "остальную функциональность" вместо внятного и членораздельного описания))
Я всё написал в первом сообщении.
blackmirror
01.02.2020, 16:23
Это уже значительно более современные процы, к тому же 32 битные
Попробуйте сделать такое на 8086, который, как и PDP-11 - 16-ти битный.
Не очень понял что именно требуется сделать, но если использовать команды jmp с кодом E9 и call с кодом E8, код в пределах сегмента будет перемещаемым. Ну и к данным можно обращаться так:
call get_data
data: db 1,2,3,4,5
get_data: pop bx
mov al,[bx+3]
Команды PDP11 конечно хороши, но под операнды места выделили многовато, а под коды команд маловато. Косвенность можно и выкинуть, а для модификации оставить только "без модификации", преддекремент, постинкеремент, и добавление соседнего регистра, до обращения к памяти если он отрицательный или после если положительный. Этих режимов нам вполне хватит для обработки элементов массива или организации стека и очереди. Хотя еще конечно напрашиваются команды загрузки и сохранения с небольшим константным смещением.
Правда всё это имеет смысл пока банк памяти у нас общий и такт шины на каждое слово нас не напрягает. А вот какой-то DSP может из 1 банка читать программу, из 2 и 3 операдны и записывать результат в 4й, и по производительности будет в 4 раза быстрее. И делать это можно с той же элементной базой, без всяких кешей и плис, проблема только в том, что в одну микросхему он не влезет - ног не хватит.
Lethargeek
01.02.2020, 16:40
Я всё написал в первом сообщении.
в этом штоле? (номер у него 15, а не 1)
- увеличение количества доступной памяти, когда из за архитектуры, промаха проектирования или привычки программистов писать раздутые программы памяти перестало хватать. Сегментные регистры 8086 - тот же MMU и попадают в эту категорию (16 битный адрес - это всего лишь 64 кб, а из за неудачной системы команд ещё и программы получались раздутыми)
ну, тогда и страничный порт на спеке - тоже mmu :v2_laugh:
не говоря уж о том, что m68k вообще не нужно такое "увеличение"
так что при сравнении с ним для x86 это не плюс, а минус
- - - Добавлено - - -
В целом - надо достаточно извратиться, что бы по полной использовать эти 256 кб без перезагрузки регистров, но технически это возможно.
выполнять код из некодового сегменте технически невозможно в принципе
в этом штоле?
По русски писать никак?
у, тогда и страничный порт на спеке - тоже mmu
Он управляет доступом к памяти? Да. Значит, mmu
выполнять код из некодового сегменте технически невозможно в принципе
А читать полностью сообщение - невозможно технически в принципе?
- - - Добавлено - - -
Команды PDP11 конечно хороши,
роблема только в том, что в одну микросхему он не влезет - ног не хватит.
Так спроектируйте процессор мечты, который подойдёт всем и для всего. Реализовать макет в FPGA - раз плюнуть. А мы потом посмотрим на результат.
А ещё лучше - возьмите технологии 70-ых и повторите сей подвиг.
А теоретизировать мы все умеем.
Black Cat / Era CG
01.02.2020, 17:15
По русски писать никак?
"По-русски".
Lethargeek
01.02.2020, 17:28
А читать полностью сообщение - невозможно технически в принципе?
а самому-то полностью понимать, что ты постишь в сообщениях, можно в принципе? :v2_rolley
надо достаточно извратиться, что бы по полной использовать эти 256 кб без перезагрузки регистров,
раз в 3/4 из этих 256 кб нельзя никакими способами выполнить код, значит, эта часть используется не "по полной"
и да, не "что бы", а "чтобы" в данном случае, о ревнитель русской словесности :v2_tong2:
нельзя никакими способами выполнить код
Для данных и стека места не надо? Или я написал - по полной использовать под код?
а самому-то полностью понимать, что ты постишь в сообщениях, можно в принципе?
Твои - понять в принципе не возможно. Как и тебе - чужие.
Lethargeek
01.02.2020, 17:45
Для данных и стека места не надо? Или я написал - по полной использовать под код?
написал "по полной" без оговорок, а раз без оговорок, то для всего :v2_dizzy_roll:
Твои - понять в принципе не возможно.
тебе - да, раз ты и свои-то понять не можешь :v2_laugh:
написал "по полной" без оговорок, а раз без оговорок, то для всего
То есть для кода, данных, стека, строк. Прямая адресация без троганья сегментных регистров у 8086 64 кб и как бы не извращаться, за пределы этого не вылезти. В сумме - 256 кб. Не можешь в уме посчитать - счёты возьми.
тебе - да, раз ты и свои-то понять не можешь
Аха. Два раза.
Lethargeek
01.02.2020, 18:23
То есть для кода, данных, стека, строк.
то есть для кода ИЛИ данных ИЛИ стека (эмулятор гарвардской архитектуры типа такой)))))
и кстати, для строковых команд x86 таки надо перезагружать сегментный регистр
или не использовать их совсем (но тогда какое же "по полной", опять-таки?)
В сумме - 256 кб. Не можешь в уме посчитать - счёты возьми.
всё могу: 64 яблока + 64 апельсина + 64 гвоздя + 64 гайки дают в сумме 256 э... эээ... единиц "использования по полной"?? :eek:
- - - Добавлено - - -
PS: ИЛИ - ИСКЛЮЧАЮЩЕЕ :D
всё могу
Угу, с пациентом все понятно. Дальше не интересно.
Может мне получится объяснить. Если запретить юзеру менять значения сегментных регистров, устанавливаемых ОС при загрузке, и делать длинные переходы (их, кстати, ассемблеры не поддерживали - приходилось байтами писать), то получаем отличный ММЮ, имея до 256 КБ на процесс с никакими затратами на релокацию - не хватает только виртуалки для полного многозадачного счастья из 100 задач разом. В лучших PDP11 дают только 128 КБ. Простейшее ММЮ - это два регистра базы (для данных и кода) и два соответствующих регистра-лимита - так и было в Танди 16, а мой знакомый такое недавно на ПЛИС запилил для поддержки Миникс на ЦП без своего ММЮ.
Формат СОМ для ДОСа наверное единственный, которому не нужен загрузчик, - это благодаря полу-ММЮ 8086. Для 68к таких форматов не было и быть не могло.
до 256 КБ на процесс
При условии, что мы уместимся кодом в 64 кб, данными - в 64 кб, данными и адресами возврата на стеке - в 64 кб, строками - в 64 кб. Если чего то из этого у нас меньше, чем на 64 кб - лишнее под другой тип инфы использовать не получится. А учитывая, что строки - это весьма специфический тип данных, я и написал - 192+64.
Формат СОМ для ДОСа наверное единственный, которому не нужен загрузчик
Загрузчик ему нужен. После загрузки не требуется править в памяти. Но - 64 кб.
Формат СОМ для ДОСа наверное единственный, которому не нужен загрузчик
Формат .SAV из RT-11 и .TSK из RSX-11 - это аналоги .COM формата.
Формат .REL из RT-11 - это аналог .EXE формата.
Ну и есть такая экзотика, как .LDA формат - его аналога как то нигде не встречал
blackmirror
01.02.2020, 19:37
Вообще-то у 8086 есть префиксы переопределения сегмента, то есть данные ему доступны из всех 256К, причём из сегмента стека он их может брать и без переопределения сегмента, если при адресации используется регистр bp. А вот у 386 появилось еще два сегментных регистра, так что в реальном режиме через префиксы ему будет доступно 384К без перезагрузки сегментных регистров.
Вообще-то у 8086 есть префиксы переопределения сегмента
Вообще то речь шла о работе без троганья сегментных регистров и без префиксов
Lethargeek
01.02.2020, 20:05
Если запретить юзеру менять значения сегментных регистров, устанавливаемых ОС при загрузке, и делать длинные переходы (их, кстати, ассемблеры не поддерживали - приходилось байтами писать),
шта? разве что совсем какие-то древние, а в масмах-тасмах, помню, были far ptr и dword ptr
то получаем отличный ММЮ,
нет, в первую очередь получаем еще более хреновый процессор, чем 8086 без этих ограничений
с одним-единственным и весьма сомнительным плюсом - чуть более быстрым запуском программ (меньше патчинга)
- - - Добавлено - - -
Вообще-то у 8086 есть префиксы переопределения сегмента, то есть данные ему доступны из всех 256К,
но не код
- - - Добавлено - - -
итого в сухом остатке сегментация 8086:
1) не даёт никакой виртуализации и защиты
2) "расширяет" память процесса хуже и меньше, чем процесс m68k имеет без таких "расширений"
3) полноценная релокация без танцев с бубном только для com (а с бубном патчить можно и без сегментов)
то есть сегменты 8086 никаким конкурентным преимуществом перед m68k являться не могут
а являются уродливым костылём, в лучшем случае позволяющим лишь немного сократить отставание
а являются уродливым костылём, в лучшем случае позволяющим лишь немного сократить отставание
А на выходе мы имеем, что из за господ менеджеров DEC таки просрала рынок с потенциально лучшей 16-ти битной архитектурой. Ибо в серии Pro они слепили из конфетки ***** (причём в определённых аспектах даже хуже PC), а серия VAX изначально была нацелена не на рынок персоналок и только потом они что то начали лепить персонально-подобное. И - запрет создания аналогов, плюс у DEC, в отличии от той же Apple, были гораздо худшие маркетологи, так что неконфетку никто не смог (да и не смог бы по любому) продать за бешенные бабки. Ну а дальше всё понятно.
Lethargeek
01.02.2020, 21:50
насчёт эффективных менеджеров не поспоришь
Вдогонку. С M68k работать не приходилось, сказать ничего не могу, на ассемблере x86-x64 много писать не приходилось, но после удобной системы команд PDP-11 - считаю крайне не удобным. А также - тот же самый (по функционалу) код на PDP-11 получается гораздо короче - спасибо и системе команд и режимам адресации. В своё время для меня было до некоторой степени шоком, что такая ограниченная по возможностям и однозадачная система MS-DOS требовала для себя столько памяти, при том что первые версии были так же написаны на ассемблере. Это то же о чём то, но говорит.
Очень странное замечание. У х86 очень хорошая плотность кодов, тут они всегда обгоняли Армы и даже которые "с пальчиком". У PDP-11 код по плотности хуже, чем на х86, где команды могут иметь длину 1 или 3 байта, а на они PDP-11 всегда кратны 2. ДОС и называли "быстрой и грязной" - скопипастели код СР/М, который был на 8080-ассемблере. Потом, кажется с версии 3, перешли на си. И чем же ДОС ограниченная по сравнению с RT-11? Имена файлов длиннее, есть каталоги и юникс-переодресация потоков, возможность делать TSR-програмы (это неофициальная, но многозадачность), памяти намного больше, ... И сама ДОС не так уж и много требовала памяти - влезала в himem. Некоторые менеджеры памяти давали до 800 кб юзеру. Конечно, программистам 80-х уже не надо было так бороться за каждый байт, как тем, кто писал RT-11 в 70-е.
При условии, что мы уместимся кодом в 64 кб, данными - в 64 кб, данными и адресами возврата на стеке - в 64 кб, строками - в 64 кб. Если чего то из этого у нас меньше, чем на 64 кб - лишнее под другой тип инфы использовать не получится. А учитывая, что строки - это весьма специфический тип данных, я и написал - 192+64.
Загрузчик ему нужен. После загрузки не требуется править в памяти. Но - 64 кб.
Формат .SAV из RT-11 и .TSK из RSX-11 - это аналоги .COM формата.
Формат .REL из RT-11 - это аналог .EXE формата.
Ну и есть такая экзотика, как .LDA формат - его аналога как то нигде не встречал
Да, код не более 64 кб, а данных до 192 кб. И почему это нельзя сегментные регистры использовать? Очень даже можно - это ММЮ никак не порушит. Нет у СОМ никакого загрузчика - это чистый код - и такого ни для какой другой архитектуры не знаю - это пример, когда процентов 20% всех возможностей из сегментов поиспользовали. А SAV и TSK имеют очень даже заметные загрузчики. В Atari ST, система которой сделана копированием ДОС и Досовского Гем, есть аналог СОМ-формата, но с загрузчиком. Не знаю что за LDA - дайте ссылку, но уверен, что и близко не ДОС СОМ.
шта? разве что совсем какие-то древние, а в масмах-тасмах, помню, были far ptr и dword ptr
нет, в первую очередь получаем еще более хреновый процессор, чем 8086 без этих ограничений
с одним-единственным и весьма сомнительным плюсом - чуть более быстрым запуском программ (меньше патчинга)
но не код
итого в сухом остатке сегментация 8086:
1) не даёт никакой виртуализации и защиты
2) "расширяет" память процесса хуже и меньше, чем процесс m68k имеет без таких "расширений"
3) полноценная релокация без танцев с бубном только для com (а с бубном патчить можно и без сегментов)
то есть сегменты 8086 никаким конкурентным преимуществом перед m68k являться не могут
а являются уродливым костылём, в лучшем случае позволяющим лишь немного сократить отставание
ДОС одназадачная система, где приоритетом выбрали использование всей памяти одним процессом, а не многими процессами её части как в PDP-11, где вас почему-то сегменты по 64 КБ не смущают никак, а некоторых даже умиляют. На 8086 вполне можно было всё хозяйство PDP-11 переносить, сегменты просто всё управление памятью разруливали. Писал уже, что ММЮ нужны только две базы и два лимита, у 8086 есть четыре (!) базы и четыре фиксированных лимита по 64 кб. Ставь Юникс запросто, только выполняй несколько простых ограничений - не пиши в сегментые регистры и не использую длинные переходы в прикладных программах, т.е. для полной защиты памяти не хватает только превилигированного режима для названных операций.
1) Да виртуализации 8086 не даёт, но защиту предоставляет хотя и не 100%.
2) Да, больше у 68000 адресуемая память, но и реализована с издержками. Грузить нужно 4 байта адреса, хотя используются только 3 - в 8086 таких тормозов нет. И, повторю, в начале 80-х один мб и более ставили только на очень дорогие системы, с которыми 68000 конкурировать не мог из-за отсутствия ММЮ и сопра. Реально преимущества 68000 перед 8086 стали доступны людям только с 1983, когда уже был 80286, который значительно шустрее 68000, имел встроенное ММЮ и поддержку сопра. Если бы на Амиги и Атари СТ поставили 80286, получились бы гораздо более крутые системы - там ДОСа не было и всё сразу можно было делать в защищенном режиме или через LOADALL - возможно и сейчас бы ещё их выпускали.
3) Это не так уж и мало - выгрузил из дебаггера код в СОМ-файл и тут же запустил его как программу - очень даже приятная особенность, которую утратили с переходом на более тяжёлые оси.
Что-то путаете, 8086/8088 появились раньше 68000 более чем на год и это было их существенным преимуществом. Интел сразу стала их производить массово, а мотороловцы наладили массовый выпуск только после 1980. Поэтому в фразе "немного сократить отставание" что-то съехало. Если вам сегменты кажутся "уродливым костылём", то возможно у вас такие вкусы. Но если хотите по существу, то предложите другой способ лучшим образом организовать адресацию памяти, чем это было сделано в х86. Только не забывайте, что вы должны сделать это для реалий 1978 с перспективой лет на 5.
Lethargeek
02.02.2020, 00:57
У х86 очень хорошая плотность кодов, тут они всегда обгоняли Армы
сие неправда, в 90-е я писал на x86 асме довольно много, и гораздо позже ради интереса переводил кое-что для арма
арм я в это время знал очень плохо (да и после не было практики) - и тем не менее плотность получалась никак не хуже
и это даже не считая того, что на арме можно было код сворачивать в короткие процедуры, всё еще опережая в скорости x86
ДОС одназадачная система, где приоритетом выбрали использование всей памяти одним процессом, а не многими процессами её части как в PDP-11, где вас почему-то сегменты по 64 КБ не смущают никак,
про пдп я вообще пока что не говорил
несколько простых ограничений - не пиши в сегментые регистры и не использую длинные переходы в прикладных программах,
совет из серии "отрубить туристу руки, чтоб легче шлось"
1) Да виртуализации 8086 не даёт, но защиту предоставляет хотя и не 100%.
только уровень защиты примерно как в той самой неприличной шутке про ПВО :D
2) Да, больше у 68000 адресуемая память, но и реализована с издержками. Грузить нужно 4 байта адреса, хотя используются только 3 - в 8086 таких тормозов нет.
зато больше есть - когда нужны 20 бит, а грузится 32 :p
и за данными лазить в память чаще приходится из-за недостатка регистров
И, повторю, в начале 80-х один мб и более ставили только на очень дорогие системы, с которыми 68000 конкурировать не мог из-за отсутствия ММЮ и сопра.
вообще-то в начале 80-х именно м68к и ставили в дорогие профессиональные рабочие станции, иногда и мультипроцессорные
Реально преимущества 68000 перед 8086 стали доступны людям только с 1983, когда уже был 80286, который значительно шустрее 68000,
сильно сомневаюсь насчёт "значительно", особенно для первых моделей (а в следующем году появился уже и 68020)
имел встроенное ММЮ и поддержку сопра. Если бы на Амиги и Атари СТ поставили 80286,
...то их в 1986 никто бы не купил из-за конских ценников (так же как и системы на 68020)
кстати, mmu производители домашних компов предпочитали свой встраивать в чипсет с учётом видеоподсистемы
3) Это не так уж и мало - выгрузил из дебаггера код в СОМ-файл и тут же запустил его как программу - очень даже приятная особенность, которую утратили с переходом на более тяжёлые оси.
не понимаю смысла этого действа - екзешный код не заработает в ком-формате (разве что мелкие чисто вычислительные фрагменты), а комовский и так в дебагере крутится
Что-то путаете, 8086/8088 появились раньше 68000 более чем на год и это было их существенным преимуществом. Интел сразу стала их производить массово, а мотороловцы наладили массовый выпуск только после 1980. Поэтому в фразе "немного сократить отставание" что-то съехало.
ничего не съехало, и кто раньше появился, тут ни при чем, вышел конкурент - появилось и отставание
(даже без учёта того, что компы на них обоих появились позже чем через год)
Если вам сегменты кажутся "уродливым костылём", то возможно у вас такие вкусы. Но если хотите по существу, то предложите другой способ лучшим образом организовать адресацию памяти, чем это было сделано в х86? Только не забывайте, что вы должны сделать это для реалий 1978 с перспективой лет на 5.
например, arm+thumb с перспективой лет так на 35 :p
(что осуществимо было чисто технически)
да и моторола именно из-за "издержек" дальше смотрела
HardWareMan
02.02.2020, 07:51
Я тут имел реальную ситуацию, которая может примерно оценить некоторые параметры при сравнении x86 и ARM. Я делал частную изменённую реализацию математики RIPEMD сначала на х86, а потом на ARM. Обе для получения максимальной скорости на ассмеблере. Вот, например, один из раундов:
ecx := Rol9( (ecx + PDWord(@HashBuf[0])^) + (((eax xor ebx) and edx) xor ebx) );
1: add ecx,dword ptr NEWHASH[0]
2: mov esi,eax
3: xor esi,ebx
4: and esi,edx
5: xor esi,ebx
6: add ecx,esi
7: rol ecx,$00000009
1: EOR R8, R0, R1
2: AND R8, R8, R3
3: EOR R8, R8, R1
4: ADD R8, R8, R4
5: ADD R2, R2, R8
6: ROR R2, R2, #23
Видно, что ARM имеет достаточно регистров, чтобы поместить в них все необходимые переменные (это два набора по 128 бит, + 64 бита исходные данные + пара регистров на времянку), а у x86 кое-что (исходные данные) приходится оставлять в памяти. Так же тройная адресация ARM экономит как минимум 1 инструкцию (далее есть раунды где экономится 2 инструкции). В итоге, пиковая производительность счёта в коротком цикле составляет примерно 10MH/s на 3GHz в одном потоке для х86 (пробовал и Pentium D и на Core i7 - одинаково) и примерно 330kH/s в одном потоке на ARM CortexM4 168MHz (STM32F4xx). Получается, что у первого 300 хэшей на 1 МГц, а у второго всего ~1,964. Длину получаемого кода не сравнивал, у ARM включен палец. Было бы интересно проверить на более мощных ARMv7+, которые умеют в гигагерцы, чтобы быть в одинаковой позиции хотя-бы по тактовой частоте.
PS Чтобы быть честным, то реализация этого алгоритма на паскале или С (первая строчка в тэге код) даёт пиковую производительность в 150-200кH/s, что даже ниже чем у контроллера. Именно перепись на ассемблер дало такой громадный скачок. Правда, какие-то ключи оптимизации компиляторов я не пробовал, но не думаю, что там будет быстрее, чем 800к. Есть мнение, что вся процедурка (а это порядка 300 инструкций) тупо поместилась в кэше процессора отсюда и такой аномальный буст. Вот так вот.
PPS Вот еще один раунд с другой математикой:
eax := Rol7( (eax+$5A827999) + (((ecx or edx) and ebx) or (ecx and edx)) );
1: add eax,$5A827999
2: mov esi,ecx
3: mov edi,ecx
4: or esi,edx
5: and esi,ebx
6: and edi,edx
7: or edi,esi
8: add eax,edi
9: rol eax,$00000007
1: ORR R8, R2, R3
2: AND R8, R8, R1
3: AND R9, R2, R3
4: ORR R8, R8, R9
5: ADD R8, R8, R6
6: ADD R0, R0, R8
7: ROR R0, R0, #25
Всё-таки тройная адресация по любому рулит.
У меня обратный опыт. Начинал с MCS51, MCS80 и x86. Потом уже М68К. А уже потом - AVR и ARM. Никаких рефлексов, чётко понимаешь плюсы и минусы той или иной архитектуры. Может всё дело в вашей вере?Нет, все проще. В вашем списке нет PDP-11. После ее архитектуры, точнее, системы команд, все остальные системы команд кажутся неуклюжими и непригодными для программирования на асме. Сразу понимаешь, что Си - тоже хороший язык, а время массового программирования на асме таки прошло... :)
--------------------------
Почитал я все, что тут написали. Люди, вы в своем споре ушли куда-то не туда. Вы что, серьезно сравниваете 16-разрядные машинки с костылями в виде разных диспетчеров памяти и нормальное 32-разрядное решение 680х0 ? Ну извините!..
Единственным преимуществом 8088 (не 8086) перед 68000 - это то, что ему хватало 8 шт. довольно дорогих в то время микросхем ОЗУ, когда всем остальным, включая 68000 их требовалось 16 шт. Ну, еще несколько дополнительных шинных драйверов и прочих регистров, грубо говоря, 74LS245 и 74LS373, всего 3-5 шт. Это я про самый первый писюк. По грубым прикидкам, баксов 500-700 в то время. Все! Как только писюки стали делать на 8086, это преимущество испарилось.
А если сравнивать 68000 и 8086, то у 86-го преимуществ нет. Вообще. Ну, кроме математического сопроцессора. Только вот в секторе х86 была реальная высокая конкуренция - эти процессоры, кроме интелей, клепали и AMD, и VIA, и, придя покупать писюк я мог попросить продавца поставить туда любой из этих процессоров. А с 68000 такого тоже не было. Ну, и еще момент. Моторола - гигатнская корпроация, у которой подразделение, занимавшееся 68000 было одной из мелочей, справляются - хорошо, нет - прикроем. А у интелей их 80х86 был основным источником существования, естественно, они, что называется, из шкуры готовы были вылезти...
Позже, когда интеля укрепились в позиции основного поставщика процессоров для писюков, они решили избавиться от конкурентов, запатентовав сокет своего процессора. Последним конкуретно-доступным процессором был Пентиум (первый) с его сокетом 7. Пришлось АМД-шникам для своих процессоров разрабатывать собственные материнские платы, а простой покупатель лишился возможности выбрать процессор для своего компа, его приходится выбирать вместе с мамашей. Тем не менее, все прорывные решения в сфере х86 пока что исходят от АМД, а не от интелей. Перенос в процессор большей части северного моста (и ликвидация этого моста), архитектура х64, сейчас вот тоже что-то новое появилось, не вникал. А интеля зажрались!..
У х86 очень хорошая плотность кодов
Плотность кода - это не возможность иметь разный размер команд, а количество команд для выполнения определённой задачи. И за счёт более разнообразных способов адресации количество команд плюс практически 100 процентная ортогональность у PDP-11 - их потребуется меньше.
Имена файлов длиннее, есть каталоги и юникс-переодресация потоков,
8+3 - это конечно, существенно длиннее, чем 6+3. Каталоги и конвейер появились только во второй версии
TSR-програмы (это неофициальная, но многозадачность)
Берём FB монитор и получаем то же самое
И почему это нельзя сегментные регистры использовать?
Используем ДП и получаем до 4 мб. Что несколько больше 1мб на 8086
И сама ДОС не так уж и много требовала памяти - влезала в himem
himem на 8086, да?
онечно, программистам 80-х уже не надо было так бороться за каждый байт, как тем, кто писал RT-11 в 70-е.
Сравните цену на память тогда и сейчас - о, зашибись, поставим ещё пару терабайт - и всё влезет. Отличный подход для раздутого кода
Нет у СОМ никакого загрузчика - это чистый код
Типа он в ОЗУ святым духом переносится. Или все таки ЗАГРУЗЧИК его читает.
А SAV и TSK имеют очень даже заметные загрузчики.
Которые одним запросом на чтение к диску читают загружаемый сегмент и передают управление. Никакого патча, как для, в общем случае, .exe
Не знаю что за LDA
То есть по PDP-11 и её системам вообще не спец, а что то пытается доказывать.
На 8086 вполне можно было всё хозяйство PDP-11 переносить, сегменты просто всё управление памятью разруливали
Перенесите RSX-11M-Plus, потом продолжим общение.
Да виртуализации 8086 не даёт, но защиту предоставляет хотя и не 100%.
От слова - никакой. Там и 1 процентом не пахнет. К тому же - защита, как и свежесть, бывает только двух видов - или она есть или её нет. Любая программа на 8086 может сделать с компом и запущенными операционкой-программой всё, что захочет.
Но если хотите по существу, то предложите другой способ лучшим образом организовать адресацию памяти, чем это было сделано в х86
MMU на PDP-11. 1973 - полноценная защита, 1975 года - бОльший объём памяти и . RSX-11M - 1974 год. Полноценная многозадачная и многопользовательская ОС. DECNet - 1974 год - поддержка компьютерных сетей
- - - Добавлено - - -
Сразу понимаешь, что Си - тоже хороший язык, а время массового программирования на асме таки прошло...
С пакетом DSMAC вообще не возникает ни желания ни необходимости использовать этот уродец
HardWareMan
02.02.2020, 10:02
himem на 8086, да?
Однако, EMS (не XMS) начинал именно как плата в ISA слот. Банкование в окно и всё такое. Это уже в процессорах с защитой и большими объемами памяти EMS стали эмулировать в EMM386 поверх XMS через himem.
Однако, EMS (не XMS) начинал именно как плата в ISA слот
Пусть. Но любой вариант о чём говорит?
И сама ДОС не так уж и много требовала памяти - влезала в himem.
Сама дос не требовала столько памяти, что её приходилось перемещать в ещё добавленную в систему память.
И я помню все эти трахи с himem.
blackmirror
02.02.2020, 10:26
Сразу понимаешь, что Си - тоже хороший язык, а время массового программирования на асме таки прошло...
У языка Си есть много недостатков и самый отвратительный это низкий приоритет побитовых операций. То что он ниже чем у сложения и вычитания, вынуждает расставлять очень большое количество скобок, и lisp тут просто отдыхает. Вообще необходимость в сдвигах и побитовых операциях возникает из-за того, что память не поддерживает обращение к данным с любого бита, и логичнее сдвигами и масками сначала вытащить что нам нужно, потом уже это складывать или делить. А время ассемблера только начинается, сейчас кто угодно в плис может засунуть такое, для чего опенсурсный компилятор придётся допиливать лет 10, прилично оптимизировать он научится лет через 30(если платформа станет популярна и превратится в микросхемку), а чтобы это было не хуже чем у людей понадобится лет 100.
вынуждает расставлять очень большое количество скобок
После того, как напрограммируешься на разных языках с несколько отличающимися приоритетами операций - скобки вставляются везде. Точно не посадишь крайне трудно (как правило) обнаруживаемые ошибки и при взгляде на выражение не нужно думать - что и в каком порядке выполняется. Проверено на личном опыте.
Вообще необходимость в сдвигах и побитовых операциях возникает из-за того, что память не поддерживает обращение к данным с любого бита
Ну вот не срослось такое. Экономия битов в адресе.
для чего опенсурсный компилятор придётся допиливать лет 10
Я последнее время не надеюсь на opensource от слова совсем. И забросить проект могут и вообще удалить и ошибки-todo висят годами и раздуваются со временем ибо все хотят вставить в проект ВСЁ.
- - - Добавлено - - -
самый отвратительный это низкий приоритет побитовых операций
У разработчиков в те времена, очевидно, была причина, почему такой. А по прошествии времени, огромного количества софта и СТАНДАРТА - с этим уже НИЧЕГО не сделать. Так что ЕДИНСТВЕННО правильный вариант - явные скобки. Сработает всегда и на любом стандарте - правильно.
HardWareMan
02.02.2020, 13:30
Нет, все проще. В вашем списке нет PDP-11.
Почитал про PDP-11. Понял, откуда растут ноги этой вашей восьмеричной системы. Всё удобство этого PDP-11 только в написании ручной трансляции программы сразу в машинные коды. Но я уже в 8 лет компилировал так практически 80% опкода от ВМ80 (в основном те, что пользовался наиболее часто), а к 10 уже достиг 100%. Так что нет, лучше уж MIPS. Мне R3000 15 лет назад залетал на ура без какого-либо отторжения.
Всё удобство этого PDP-11 только в написании ручной трансляции программы сразу в машинные коды.
Нет. Основные удобства - практически ортогональная система команд и большое количество режимов адресации, особенно с автодекрементом и автоинкрементом. Так же плюсом в те времена, да и в принципе сейчас - аппаратный стек любого (в пределах 16 бит) размера, возможность создать стек (причём не один) на любом регистре (пусть шестой регистр и имел сакральный смысл), гибкая система прерываний (любое устройство можно было повесить на любой вектор трогая само устройство, а не какое либо другое устройство или код) и отображённый в адресной пространство проца доступ к регистрам устройств.
Да, сейчас большинство этих возможностей доступно штатно, но не тогда
Ну и чем должна закончится столь интересная и плодотворная дискуссия?
Составлением сравнительной энциклопедии архитектур?
Выбором кандидата для "топологии последнего шага" МЭ? Но тут опять будут решать, к сожалению деньги.
Выбором кандидата для российской космической программы в радиационно-стойком исполнении.
Наиболее популярной архитектуры для российского компьютерного андеграунда? с ядром на FPGA, и на MCU/CPU
Наиболее популярной архитектуры для стихийного народного технического творчества на кухне и "на коленке"
Ну и чем должна закончится столь интересная и плодотворная дискуссия?
Чем чем. Все дружно пойдут пить пиво :)
HardWareMan
02.02.2020, 17:12
Так-то пиво уже выпито. А завтра кто-то должен идти на работу. А я так вообще живу на ней, хотя некоторые завидуют: о, работаешь дома, класс.
Да, сейчас большинство этих возможностей доступно штатно, но не тогда
Что ещё раз подтверждает, что каждая архитектура хороша в своё время. Впрочем, как и языки программирования. Где сейчас этот ваш фортран?
Что ещё раз подтверждает, что каждая архитектура хороша в своё время.
Особенно такое *****, как IBM PC. На века, так сказать, ибо трудно снести эту гору.
Где сейчас этот ваш фортран?
Используется весьма неплохо в научных кругах. В своё время было написано большое количество библиотек, реализующих стандартные вычислительные методы - как то не сильно быстро они переписываются на что то другое.
сие неправда, в 90-е я писал на x86 асме довольно много, и гораздо позже ради интереса переводил кое-что для арма
арм я в это время знал очень плохо (да и после не было практики) - и тем не менее плотность получалась никак не хуже
и это даже не считая того, что на арме можно было код сворачивать в короткие процедуры, всё еще опережая в скорости x86
3вучит абсолютно несерьёзно, общался с армовцами: для них состязатся по плотности х86 - это абсурд. Хотя арм-с-палец иногда и может обгонять х86 по плотности, но смотрите данные в сети - коды х86 все-таки плотнее. И палец делает код иногда существенно тормознее. Если у вас не только шутки, то давайте пример. А скорость х86 очень зависит от типа и частоты. АРМ на 8 МГц мог обогнать 80386 на 25 МГц на многих задачах, а вот АРМ на 25 МГц если и обгонял 80486 на той же частоте, то чуть-чуть. Стронг АРМ мог тягаться с первыми Пентиумами, но уже не с вторыми.
про пдп я вообще пока что не говорил
Говорили, что 64 кб - мало, а на пдп больше и не дают.
только уровень защиты примерно как в той самой неприличной шутке про ПВО :D
Повторю опять, если программист придерживается правил, а не пишет вирусы, то защита будет почти идеальная.
и за данными лазить в память чаще приходится из-за недостатка регистров
Так половина регистров - адресные - для кэша данных годились, но для полноценной работы нет.
вообще-то в начале 80-х именно м68к и ставили в дорогие профессиональные рабочие станции, иногда и мультипроцессорныеО том и речь, что системы с 68000 были довольно дороги. IBM сделала ПК на 68000 в 1982, но получилось дорого, не пошло. Ставили в относительно дорогое железо, потому что 68000 был самым дешёвым из дорогих и имел довольно высокие тактовые частоты.
сильно сомневаюсь насчёт "значительно", особенно для первых моделей (а в следующем году появился уже и 68020)
68000, 68010, 68020, 68030 очень тормознуто работали с памятью и байтами.
...то их в 1986 никто бы не купил из-за конских ценников (так же как и системы на 68020)
кстати, mmu производители домашних компов предпочитали свой встраивать в чипсет с учётом видеоподсистемы
Но амиги хорошо пошли как раз с 1987. А что за домашние пк с ММЮ? Не знаю таких. Коммодор 128? Там есть что-то с таким названием, но его возможности очень малы - что-то типа расширенного банкования. Ни Маки, ни Амиги, ни Атари СТ ММЮ на 68000 не имели. Амиги и Атари не получили его и с 68020. А первый ПК, относительно доступный, с ММЮ - это PC AT.
не понимаю смысла этого действа - екзешный код не заработает в ком-формате (разве что мелкие чисто вычислительные фрагменты), а комовский и так в дебагере крутится
Ясно, что не более 64 кб. А смысл - накодили в дебаггере и слили сразу в машинный код без ассемблирования - программа готова к исполнению. Например, нужен код нужный видеорежим включить.
например, arm+thumb с перспективой лет так на 35 :p
(что осуществимо было чисто технически)
32-разрядные регистры в 1978?! АРМ-С-Палец сделали только вроде к середине 90-х. Интересные шутки.
Плотность кода - это не возможность иметь разный размер команд, а количество команд для выполнения определённой задачи. И за счёт более разнообразных способов адресации количество команд плюс практически 100 процентная ортогональность у PDP-11 - их потребуется меньше.
Если вы серьёзно, то дайте практический код.
8+3 - это конечно, существенно длиннее, чем 6+3. Каталоги и конвейер появились только во второй версии
8 - это прирост очень даже заметный, 33%. А версия 2 уже 1982 вышла.
Используем ДП и получаем до 4 мб. Что несколько больше 1мб на 8086
И сколько на задачу? Менее 64кб и не больше для Rt-11 или более продвинутых Unix и почти Vax - RSX-11. А в ДОСе вам 640кб мало - что-то не сходится.
Типа он в ОЗУ святым духом переносится. Или все таки ЗАГРУЗЧИК его читает.
Загрузчик код готовит к исполнению, а тот он не нужен - код уже готов. В озу его переносит функция чтения с диска - ничего другого не надо.
Которые одним запросом на чтение к диску читают загружаемый сегмент и передают управление. Никакого патча, как для, в общем случае, .exe
А как же работа с https://en.wikipedia.org/wiki/Relocation_(computing)#Relocation_table ?
Перенесите RSX-11M-Plus, потом продолжим общение.
Работа большая.
От слова - никакой. Там и 1 процентом не пахнет. К тому же - защита, как и свежесть, бывает только двух видов - или она есть или её нет. Любая программа на 8086 может сделать с компом и запущенными операционкой-программой всё, что захочет.
Придерживаться правил при написании софта - это обычная практика. Все первые виндузы легко было сломать, если не писать коды корректно. И ДОС-программа могла легко систему порушить. Однако к 1995 сотни миллионов пользователей в этой системе сидели. Потом Билл решил срубить миллиард и срубил не один. А его конкурент Килдал погиб.
С пакетом DSMAC вообще не возникает ни желания ни необходимости использовать этот уродец
3ачем ЯВУ нужны?! Есть же машинный код!
Особенно такое *****, как IBM PC. На века, так сказать, ибо трудно снести эту гору.
И как же вы такое г. использовали? Нравилось? Или вы что-то продаёте? :)
А как же работа с https://en.wikipedia.org/wiki/Reloca...location_table ?
Ни в .SAV, ни в .TSK нет этих таблиц. Оба формата - образ памяти. Читается с диска одним запросом. И выдаёт этот запрос модуль загрузчика
- - - Добавлено - - -
Работа большая.
Да вы что. То есть - не можете.
- - - Добавлено - - -
Придерживаться правил при написании софта - это обычная практика. Все первые виндузы легко было сломать, если не писать коды корректно. И ДОС-программа могла легко систему порушить.
А в RSX я могу что угодно творить в программе - и это порушит только эту программу. Недаром есть в Канаде атомные электростанции, которыми до сих пор PDP-11 управляет. Представляю, чего было бы, поставить туда писюк. Даже современный
- - - Добавлено - - -
3ачем ЯВУ нужны?! Есть же машинный код!
На PDP-11 - желание использовать их - не возникает. MACRO-11 с макросами делает это не нужным. После примерно так 20-ти летнего перерыва - язык ассемблера вспомнился на ура.
- - - Добавлено - - -
И сколько на задачу? Менее 64кб и не больше для Rt-11 или более продвинутых Unix и почти Vax - RSX-11
До 4мб минус память, занятая системой и системными процессами. То есть вот на стоящем рядом новодельном Кванте - до примерно 3+ мб
- - - Добавлено - - -
Квант был куплен примерно в 87 году. На него перенесена RSX. Получился ПК с многозадачной и многопользовательской системой. Что у нас тогда на писюках было? MS-DOS и Windows 2.0?
Добавлено.
Ошибся с годом покупки. Скорее всего - лето 93-его.
Lethargeek
06.02.2020, 14:20
3вучит абсолютно несерьёзно, общался с армовцами: для них состязатся по плотности х86 - это абсурд. Хотя арм-с-палец иногда и может обгонять х86 по плотности, но смотрите данные в сети - коды х86 все-таки плотнее. И палец делает код иногда существенно тормознее. Если у вас не только шутки, то давайте пример.
бгггг, посмотрел данные в сети и даю пример: https://stardot.org.uk/forums/viewtopic.php?f=29&t=15941
действительно, абсурд :v2_crazy: хорошо, если не шизофрения (хотя ник, тогда, наверно, был бы другой) :v2_huh:
А скорость х86 очень зависит от типа и частоты. АРМ на 8 МГц мог обогнать 80386 на 25 МГц на многих задачах, а вот АРМ на 25 МГц если и обгонял 80486 на той же частоте, то чуть-чуть.
только был при этом в разы дешевле (как и дальнейшие)
Стронг АРМ мог тягаться с первыми Пентиумами,
что говорит о реальном качестве распиаренной "суперскалярности" в первопнях :v2_dizzy_biggrin2:
Говорили, что 64 кб - мало, а на пдп больше и не дают.
см. выше, где уже отвергли инсинуацию
Повторю опять, если программист придерживается правил, а не пишет вирусы, то защита будет почти идеальная.
эхехе, звучит как "если враг не будет заряжать пушку и прицеливаться в наш танк, то защита у нашего танка почти идеальная"
алло, те, кто в танке! защита для того и предназначена, чтобы защищать систему от некорректных действий софта!
если вместо выражается робкая надежда, что некорректных действий не будет, то это по определению не защита
Так половина регистров - адресные - для кэша данных годились, но для полноценной работы нет.
алло, речь была всё еще про арм, какие адресные регистры? впрочем, если хочется притянуть сюда моторолу, так у неё одних регистров данных столько же, сколько всех недо-РОН у x86 (даже не учитывая разрядность) + адресные разгружают их дополнительно
О том и речь, что системы с 68000 были довольно дороги. IBM сделала ПК на 68000 в 1982, но получилось дорого, не пошло. Ставили в относительно дорогое железо, потому что 68000 был самым дешёвым из дорогих и имел довольно высокие тактовые частоты.
ага, особенно всякие амиги-атари были дороги, особенно по сравнению с ибм на x86 :v2_rolley
а в дорогих системах на моторолах основная стоимость приходилась не на процессор
и процессор после всех затрат уже выбирали из доступных какой получше
68000, 68010, 68020, 68030 очень тормознуто работали с памятью и байтами.
"очень" - это скока? для каких конфигураций? примеры будут?
и сильно зависело от машины, тот же 286 в условной "нерасширенной амиге" без "быстрой памяти" был бы тормознее, чем в песюке
что за домашние пк с ММЮ? Не знаю таких. Коммодор 128? Там есть что-то с таким названием, но его возможности очень малы - что-то типа расширенного банкования. Ни Маки, ни Амиги, ни Атари СТ ММЮ на 68000 не имели. Амиги и Атари не получили его и с 68020. А первый ПК, относительно доступный, с ММЮ - это PC AT.
:v2_dizzy_facepalm: что за ММЮ на PC AT? не знаю такого!
зато знаю про многозадачность с многооконностью на амигах и особенно архимедах
(ага, в отличие от "первого относительно доступного с ММЮ")))
Ясно, что не более 64 кб. А смысл - накодили в дебаггере и слили сразу в машинный код без ассемблирования - программа готова к исполнению. Например, нужен код нужный видеорежим включить.
хрень какая-то для совсем уж нищих конфигураций (может, даже без дисковода))
32-разрядные регистры в 1978?! АРМ-С-Палец сделали только вроде к середине 90-х. Интересные шутки.
палец тут вообще ни при чём, и что такого в 32-битных регистрах? за 20 лет до этого и побольше были уже разрядности
тут ближе к проблеме реализуемости, сколько на кристалле транзисторов - и у арма-2 оных даже меньше, чем у 8086
Ни в .SAV, ни в .TSK нет этих таблиц. Оба формата - образ памяти. Читается с диска одним запросом. И выдаёт этот запрос модуль загрузчика
Но загрузчик есть. Вот в мой программке кода согласно листингу от макро-11 889 байт, а размер сава - 1536. Могу предположить, что в саве есть загрузчик. С tsk всё плохо - бинарники с RSX11 даже не перенести в другую систему - там файлы с метаданными, а в самой системе нет даже точного размера файлов. :(
А в RSX я могу что угодно творить в программе - и это порушит только эту программу. Недаром есть в Канаде атомные электростанции, которыми до сих пор PDP-11 управляет. Представляю, чего было бы, поставить туда писюк. Даже современный
С защитой памяти у продвинутых PDP11 всё в порядке - ничего удивительного в примере нет. А то что где-то на опасных производствах экономят и не ставят более современный софт - это скорее грустно. Хотя если там реально совсем простой контроль, может и сгодится. Возможно такое кое-где уже и на эмуляторах давно, с компьютерами на х86. Не случайно, эмулятор е11 продают за деньги - наверное для подобных случаев. С другой стороны, сравнивать технику, устаревшую уже к середине 90-х, с современной как-то ещё грустнее.
На PDP-11 - желание использовать их - не возникает. MACRO-11 с макросами делает это не нужным. После примерно так 20-ти летнего перерыва - язык ассемблера вспомнился на ура.
А вы думаете в других системах макросов нет? А вот макро-11 даже просчитать сдвинутый переход вперед не может - все известные мне ассемблеры для х86 и других систем могут.
До 4мб минус память, занятая системой и системными процессами. То есть вот на стоящем рядом новодельном Кванте - до примерно 3+ мб
Обычная для топовых PDP11 картинка, но пользователю - не более 64 кб на процесс и это всё вместе - программа, данные, стек. СОМ-файл после загрузки мог всю память использовать 640 кб и даже больше.
Квант был куплен примерно в 87 году. На него перенесена RSX. Получился ПК с многозадачной и многопользовательской системой. Что у нас тогда на писюках было? MS-DOS и Windows 2.0?
В 1987?! Если не ошибаюсь в году 88 видел ДВК в магазине - стоило 15000 руб. Понимаю вашу эмоциональность. Крутой у вас был комп, но за такие деньги тогда и PC AT из штатов могли превезти или несколько амиг. Писюк был бы раза в два-три быстрее вашего кванта и игр там было много, а на амигах ещё больше. А если вам нужна была многозадачность с хорошей защитой, то на писюк можно было поставить и Зиникс, довеском к ДОСу.
бгггг, посмотрел данные в сети и даю пример: https://stardot.org.uk/forums/viewtopic.php?f=29&t=15941
действительно, абсурд :v2_crazy: хорошо, если не шизофрения (хотя ник, тогда, наверно, был бы другой) :v2_huh:
Если бы вы покапали получше, та нашли бы, что этот пример было специально выбран, чтобы показать преимущество 68к по плотности кодов. Там адресные регистры используются как временная память, а у х86 регистров не хватает. Кстати, лучший полученный код для рисования линии для х86 - 81 байт. Код для Арма используют трудные трюки, а код для х86 - совсем пpостой. Другой пример, перевод числа в десятичный формат показал значительное преимущество х86. Код по затворному пи получился одинаковым по размеру (136 байт), но амигавцам для этого пришлось писать ненормальный код, использующий стек, который надо заранее для программы в системе выделить. Но это всё частности, а тут (https://heyrick.eu/armwiki/RISC_vs_CISC) сами армовцы конкретно признают code density is less so an application in RISC is likely to consume more memory than the equivalent in CISC и такого можно найти ещё в весьма солидных источниках.
что говорит о реальном качестве распиаренной "суперскалярности" в первопнях :v2_dizzy_biggrin2:
Дековский Стронг Арм - это был очень крутой проц - Интел сразу его купила и до сих пор модифицирует и штампует.
см. выше, где уже отвергли инсинуациюЗайдите в любую пдп-11 систему и там все программы не более 64 кб, и на процесс те же 64 кб. И это при том, что памяти может быть 4 мб.
эхехе, звучит как "если враг не будет заряжать пушку и прицеливаться в наш танк, то защита у нашего танка почти идеальная"
алло, те, кто в танке! защита для того и предназначена, чтобы защищать систему от некорректных действий софта!
если вместо выражается робкая надежда, что некорректных действий не будет, то это по определению не защита
Повторю, "танк" с ДОСом или Виндузом нормально работал для сотен миллионов юзеров, пока Билл его не продал. Амиги и Атари СТ и 8-битная мелоюзга также нормально работали для миллионов.
алло, речь была всё еще про арм, какие адресные регистры? впрочем, если хочется притянуть сюда моторолу, так у неё одних регистров данных столько же, сколько всех недо-РОН у x86 (даже не учитывая разрядность) + адресные разгружают их дополнительно
У Арм с регистрами всё в порядке, речь была именно о 68к. Регистров у 68000 столько же, сколько у х86, а адресные - это полурегистры, костыль под архитектуру ПДП-11, работать через них с данными можно только очень ограниченно. Хотя иногда их использование и даёт преимущество. Зато х86 имеет больше регистров, если работать с байтами.
ага, особенно всякие амиги-атари были дороги, особенно по сравнению с ибм на x86 :v2_rolleyДа, IBM PC предназначались изначально для офисов и были сравнительно дороги (но заметно дешевле более тормозных Маков). Наверное амиги и т.п. с 80286 - это было бы очень дорого, но с 80186 наверное получилось бы супер, не дороже, чем с 68000. 80186 был заметно дешевле и ненамного медленнее 80286.
а в дорогих системах на моторолах основная стоимость приходилась не на процессор
и процессор после всех затрат уже выбирали из доступных какой получше
А том и речь, что Интел всегда имела более дешевые аппаратные компоненты для своих процов.
"очень" - это скока? для каких конфигураций? примеры будут?У них у всех цикл обращение к памяти был 4 такта. 80286 - 2, у Арма - 1. Помню об этом со скрытым юмором писали в Byte - cтандартный цикл моторола. :) 68000 по нескольким важным параметрам превосходил 8086, была статья в том же байте года 1984, где на 68000 странно нападали - типа плохой процессор, ничего на нем нормально не работает - похоже в Интел нервничали, но в той же статье уже хвалили 68020. А 68020 сбился с пути, продолжил копировать ПДП-11 двойными косвенными обращениями и прочими неважными сложностями, трудными для разгона.
и сильно зависело от машины, тот же 286 в условной "нерасширенной амиге" без "быстрой памяти" был бы тормознее, чем в песюкеЭто верно, но сам-то 80286 или 80186 побыстрее 68000.
:v2_dizzy_facepalm: что за ММЮ на PC AT? не знаю такого!
зато знаю про многозадачность с многооконностью на амигах и особенно архимедах
(ага, в отличие от "первого относительно доступного с ММЮ")))
В 80286 есть нормальный ммю и вы это знаете. На амигах не было никакого ммю и это вы знаете. А вот на Архимедах ммю ставили, но базовая система RiscOS так до сих пор (с ней продолжают работать - довольно неплохо смотрится на Пи с малиной) и осталась лишь условно многозадачной - там, например, при выходе в консоль, все процессы замирают.
хрень какая-то для совсем уж нищих конфигураций (может, даже без дисковода))Вы не поняли. Вам нужна маленькая программка, вы ее быстро набираете мнемониками и тут же сливаете на диск.
палец тут вообще ни при чём, и что такого в 32-битных регистрах? за 20 лет до этого и побольше были уже разрядности
тут ближе к проблеме реализуемости, сколько на кристалле транзисторов - и у арма-2 оных даже меньше, чем у 8086
Мотороловцы тоже хотели устроить как и Мао Цзедун большой скачок в 32 бита, успели только к 1979-80 и надорвались - ещё было не время.
Вот в мой программке кода согласно листингу от макро-11 889 байт, а размер сава - 1536. Могу предположить,
С tsk всё плохо - бинарники с RSX11 даже не перенести в другую систему - там файлы с метаданными, а в самой системе нет даже точного размера файлов
Вы сначала доки почитайте, а то ваши предположения говорят только об одном - о полном незнании темы
А то что где-то на опасных производствах экономят и не ставят более современный софт - это скорее грустно.
Аха, потому что этот ваш современный софт - полное Г с точки зрения защиты, потребления ресурсов и реал-тайм реакции
пользователю - не более 64 кб на процесс
Ещё раз - полное незнание темы
стоило 15000 руб. Понимаю вашу эмоциональность. Крутой у вас был комп, но за такие деньги тогда и PC AT из штатов могли превезти или несколько амиг.
За те деньги, за которые я купил тогда Квант, я не мог позволить себе (в те времена) даже XT. А вы память в утиль сдайте, глючит она
- - - Добавлено - - -
Общий вывод. Человек абсолютно не в теме, можно время не тратить.
HardWareMan
09.02.2020, 11:06
У них у всех цикл обращение к памяти был 4 такта. 80286 - 2, у Арма - 1.
Эм...
https://jpegshare.net/images/0a/07/0a07694d37bb2797b48269efe3aa7dc4.png
https://jpegshare.net/images/ca/a6/caa6742b8199cd2776a7519146cdf142.png
Иными словами - все те же 4 внешних такта на обращение, без учёта тактов ожидания. Садись, два.
Пример запущенной программы, размер которой (чуть больше) 2Мб или как более привычно для PDP-11 - 1 мегаслово
RSX-11M-PLUS V4.6 BL87 (KPXX01) 2044K UP 000:01:08 2020-02-09 13:21:52
TASK= *IDLE* FREE= SY0:176277. U2:498921.
DU1:175203. U3:2005018. PARS
POOL=4300.:4334.:15. SECPOOL=360.:512.:70%
4300.:4334.:15. 360.:512.:70% SECPOL:P
SYSPAR:D
IN DTD.FM.SB T DRVPAR:D
12 IKU.CI.YA T GEN :D
68 RT:.SM.SP 0
OU 1N ARTML0
0 1 TE0AO
0K M .S CG
!!])+!>+>>----------------------------------------------------
0*******127*****255*****383*****511*****638*****76 6*****894*****
PPD-DD----------------------------------------------------------
----------------------------------------------------------------
1022****1149****1277****1405****1533****1660****17 88****1916****
-----------+>
R ERRSEQ
M 0.
D
T
0
Программа была запущено на терминале TT0:, поэтому её имя (при запуске не задавалось) - TT0. В нижней половине полосы памяти справа от программы видна запущенная программа RMDT0, которая и показывает эту картинку. Ну, те кто ДЕЙСТВИТЕЛЬНО работали в RSX - и программу RMD и эту картинку хорошо знают.
- - - Добавлено - - -
Спрямлённый показ - память одно линейкой:
RSX-11M-PLUS V4.6 BL87 (KPXX01) 2044K UP 000:01:15 2020-02-09 13:29:12
TASK= *IDLE* FREE= SY0:176277. U2:498921.
DU1:175203. U3:2005018. PARS
POOL=4300.:4334.:15. SECPOOL=360.:512.:70%
4300.:4334.:15. 360.:512.:70% SECPOL:P ERRSEQ
SYSPAR:D 0.
DRVPAR:D
GEN :D
IN DTD.FM.SB T R
12 IKU.CI.YA T M
68 RT:.SM.SP 0 D
OU 1N ARTML0 T
0 1 TE0AO 0
0K M .S CG
!!])+!>+>>---------------------------------------------------------------+>
0*******127*****255*****383*****511*****638*****76 6*****894*****1022****1149****1277****1405****1533 ****1660****1788****1916****
PPD-DD--------------------------------------------------------------------------------------------------------------------------
Сначала поправлюсь - самый мне известный короткий код для рисования линии для х86 занимает 77 байт - поменьше Арма, но побольше 68к.
Вы сначала доки почитайте, а то ваши предположения говорят только об одном - о полном незнании темы
Cами значит не знаете. Грусто.
Аха, потому что этот ваш современный софт - полное Г с точки зрения защиты, потребления ресурсов и реал-тайм реакции
А это что ещё такое? Вы ПДП-11 с современными контроллерами сравниваете?!
За те деньги, за которые я купил тогда Квант, я не мог позволить себе (в те времена) даже XT. А вы память в утиль сдайте, глючит она
Не знаю, что у вас за Квант. Сами уже забыли? Вам по-доброму - факты, а вы хамите. :(
Иными словами - все те же 4 внешних такта на обращение, без учёта тактов ожидания. Садись, два.
Спасибо, отличнику! Но как он такой умный объяснит, что MOV из памяти выполняется на 80286 выпоняется всегда за 3 такта, а на 68030 за от 5 до 42 (если повезет с кэшем, то от 3 до 30).
Пример запущенной программы, размер которой (чуть больше) 2Мб или как более привычно для PDP-11 - 1 мегаслово
Это какой-то системный процесс? Mожете показать его файл в листинге каталога? Если знаете нормальную программу для RSX-11, большую 64кб, дайтe ссылку на компьютере BQT. И почему макро-11 забыли, который простые переходы просчитать не может? Почему не используете любимое слово на букву г? У нас обычно работали с RT-11 или Unix. На этом форуме постов, связанных с RT-11, раз в 100 побольше, чем для других пдп11 осей. Там тоже знаете супер-код, больший 64 кб?
Cами значит не знаете. Грусто.
.SAV. Первый блок - некоторое количество ячеек со служебной информацией (типа - точка входа, начальное значение стека, размер загрузки) плюс свободные ячейки и место под стек (если по умолчанию, то начальное значение стека 1000(8)). Если специально не задавать значение стека и не играться абсолютными секциями, код и данные пойду с адреса 1000, и в .SAV файле это будет второй блок. То есть, если не принимать специальных мер, минимальный размер программы в RT - 2 блока. При тех же условиях в RSX - 4 блока (первые два - служебная информация).
Вот в мой программке кода согласно листингу от макро-11 889 байт, а размер сава - 1536
889(10) байта - два блока - итого размер .SAV три блока или 512*3=1536 байт. Фраза выше говорит о полном не знании даже RT
Вы ПДП-11 с современными контроллерами сравниваете?!
Аха. И применение на атомных станциях PDP говорит о полном Г среди современных контроллеров.
Не знаю, что у вас за Квант.
И я про тоже - полное не знание фактов.
Это какой-то системный процесс?
В RSX нет понятия системных процессов. Есть ядро, есть драйвера, есть задачи (task), которые часто по простому называют программами. Некоторые задачи выполняет специальные функции (например, F11ACP - работа с файловой системой, все запросы к файлам идут через неё, но с точки зрения RSX - это задача)
Mожете показать его файл в листинге каталога?
.TITLE TEST
.MCALL RDBBK$, WDBBK$
.MCALL CRRG$S, CRAW$S
.MCALL SPND$S
.MCALL EXTK$S
.MCALL EXIT$S
.LIST ME
START:
CRRG$S #RDB
MOV RDB+R.GID, WDB+W.NRID
CRAW$S #WDB
SPND$S
EXIT$S
RDB: RDBBK$ 100000, , , <RS.ATT!RS.DEL!RS.EXT!RS.WRT!RS.RED>
WDB: WDBBK$ 1, 200, 0, 0, 200, <WS.64B!WS.MAP!WS.DEL!WS.EXT!WS.WRT!WS.RED>
.END START
[* КОНЕЦ ТЕКСТА *]
сли знаете нормальную программу для RSX-11, большую 64кб, дайтe ссылку на компьютере BQT.
Текст "супер-программы" приведён выше
И почему макро-11 забыли, который простые переходы просчитать не может?
Потому что, в отличии от вас, я знаю - особенности системы команд PDP-11 и как работает Macro-11 и почему он не может "просчитать" простые переходы
У нас обычно работали с RT-11 или Unix
А в нормальных конторах работала многопользовательская RSX с памятью от мегабайта (например СМ-1420 или СМ-1600) и нормальной поддержкой программ, которым требуется немного больше памяти, чем 64 кб. Компиляторы с Fortran-а, кстати, генерировали код, который умел это дело.
На этом форуме постов, связанных с RT-11, раз в 100 побольше, чем для других пдп11 осей. Там тоже знаете супер-код, больший 64 кб?
А в RSX и XM мониторе подход очень похожий, так что написать программу особого труда не составит. Кстати, опять же - компилятор с Fortran-а позволял писать программы, которым требовалось больше 64 кб, причём в наличии было два варианта библиотек поддержки - для программы, которая будет работать под XM монитором (по сути аналогичный подход, как и в RSX) или (внезапно) под SJ или FB, при условии, что проц PDP с MMU и размером памяти больше 56 кб
В целом, вывод не изменился - знания PDP-11 у человека на уровне начинающего чайника. Можно больше не обращать внимания на его перлы про PDP-11 и ОС для PDP-11
- - - Добавлено - - -
А это пример программы (на MACRO-11) (загружает virgin (когда загрузчик RSX ещё не прописан в нулевой сектор раздела) RSX из под RT на CF )
R$$T11 = 1
M$$EXT = 1
.NLIST
.INCLUDE /KXX:DSMAC.MAC/
.INCLUDE /KXX:MYMAC.MAC/
.INCLUDE /KXX:ASCII.MAC/
.INCLUDE /KXX:HWDF.MAC/
.LIST
MODULE NAME=<BOOTZF>, VER=<01>, COMM=<BOOT RSX from ZF>, TYPE=<NOSECT>
.MCALL .ASSUME
;
; This module contains a special driver used by BOOT and SAVE
; to read and write system images.
;
; Driver inputs:
; R2 = Not used
; R3 = Not used
; R4 = Unit number
; R5 = 0 Use CSR address stored in the driver
; R5 <> 0 use CSR address stored in R5
;
; Driver outputs:
; R0 = Residual block count
; R2 = Possible memory size from configuration table
; R1 = Device name in ascii
; R4 = Physical unit number
; R5 = CSR address
;
; INITIALIZE PROPER BIT SETTING FOR SSR3
;
S3$BTS==0 ; INIT TO NO BITS SET
.IF DF M$$EXT
S3$BTS==S3$BTS!MM3.UN!MM3.22 ; ENABLE 22 BIT MODE AND UNIBUS MAP
.ENDC
PROCEDURE BOOTZF
BEGIN
;
; from SAVe - code analog
;
NOP ; 00
GOTO 10$ ; 02
HLBN: .WORD 0 ; 04 high lbn
LLBN: .WORD 26084.+2 ; 06 low lbn 26084 + 2
; magic number
.BYTE 020 ; 10 PDP-11 instruction set
.BYTE 133 ; 11 All controllers except pcxxx
.BYTE 041 ; 12 ODS-1 file format
.BYTE 163 ; 13 1's compliment checksum
10$:
GOTO 20$
20$:
LET @#PS :B= #PR7
;
; For virgin system image
;
LET BBLKH := @#4 ;;; (HIGH) LBN of image
LET BBLKL := @#6 ;;; (LOW) LBN of image
LET BLEN := ZFLLEN ;;; length of load file
LET R5 := (PC)+ ; Csr address - set in savcm or minjbb
$BBCSR: .WORD 1
; Default to what boot rom passed
; (0= use CSR in special driver)
; (+ = use value passed in r1)
; (- = use value stored in $BBCSR)
IF RESULT IS GT THEN ; LE - in IO page
LET $BBCSR := R1 ; CSR from hardware boot
END
IF #MM0.EN OFF.IN @#SSR0 THEN
LET R5 := #KISAR0 ;;; INIT POINTER TO MAPPING REGISTERS
LET R1 := #0 ;;; INIT I SPACE MEMORY OFFSET
REPEAT
LET KISDR0-KISAR0(R5) := #77406 ;;; SET I SPACE 4K RW
LET (R5)+ := R1 ;;; SET I SPACE APR OFFSET
LET R1 := R1 + #200 ;;; ADVANCE I SPACE OFFSET
UNTIL R5 HI #KISAR7 ;;; DONE YET? IF HI YES
LET @#KISAR7 := #177600 ;;; SET UP I/O PAGE MAPPING
.IF DF M$$EXT
LET @#SSR3 := #S3$BTS ;;; SET UP SSR3
.ENDC
LET @#SSR0 := @#SSR0 + #1 ;;; MM0.EN == 1 ; ENABLE MAPPING
END
; 00000000-03777777
; 04000000-07777777
; 10000000-13777777
; 14000000-17777777
; 14000000-14777777
; 15000000-15777777
; 16000000-16777777
; 16776000 -> 167760
; 2000
; 17000000-17777777
LET @#KISAR6 := #167760 ;;; SET 140000 MAPPING
LET R4 := #140000
LET R1 := #0
THRU R3 := #256.*2
LET (R4)+ := (R1)+
END
LET R2 := #0
LET R4 := R0 ; R0 from hardware boot - unit number
IF RESULT IS PL THEN ; If MI, this is the second incarnation
LET SP := #3000 ; Set up stack for special driver
LET PUSH := #0 ; put on a stopper
LET PUSH := #0 ; two parts
END
LET R5 := $BBCSR ; CSR from hardware boot
LET SP := #$ZFDRV-BOOTZF+140000
JMP @#$ZFDRV-BOOTZF+140000
.BLKW 20. ; Stack
$GOTO $ZFDRV
END BOOTZF
;
; Special driver
;
PROCEDURE $ZFDRV
; Note - At this point the following must be true:
; R0 = unit number from hardware bootstrap, possibly with flag bit
; R2 = 0 tell the driver not to use UMRs
; R3 = 0 no BAE offset needed
; R4 = unit number from hardware bootstrap, possibly with flag bit
; R5 = 0 or the CSR address (see $BBCSR above)
BEGIN
GOTO ZF0 ;;; Br around fixed stuff
SZFNAM: .WORD "ZF ;;; Device name
SZFCSR: .WORD ZFBASE+P$CSR2 ;;; Default CSR address
SZFFUN: .BYTE CS.RD, -1 ;;; Function code and unit number
ZF0:
IF R5 EQ #0 THEN
LET R5 := SZFCSR ;;; CSR address supplied? If no, get saved CSR address
END
LET SZFCSR := R5 ;;; save CSR
LET SZFFUN+1 :B= R4 ;;; save unit number
LET R5 := SZFCSR ;;; get saved CSR address
LET (PC)+ := @#KISAR3
SKxSAR: .WORD 0
LET R1 := (PC)+ ;;; Get buffer address
ZFSA: .WORD 0
LET CARRY := CLEARED ;;; Convert to 32wd block address
LET R1 := R1 L.ROTATE 2
SWAB R1
LET ZFSA := R1
LET R3 := PC + #<SZFFUN-.> ;;; Set address for pic code
LET (PC)+ := @#4 ;;; Save starting block number
ZFBLKH: .WORD 0 ;;; Current LBN (HIGH)
LET R1 :B= 1(R3) OFF.BY #^C<377>
MUL #40, R1 ;;; offset for 1Gb
LET ZFBLKH := ZFBLKH + R1 ;;; OFFSET
LET (PC)+ := @#6 ;;; ...
ZFBLKL: .WORD 0 ;;; Current LBN (LOW)
IFB #CS.RD NE (R3) THEN ;;; Is this a write function?
LET MOVE := (PC)+ ;;; Set generic fill silo instruction
LET (R2) := (R1)+ ;;; Fill silo instruction
END
;
; Common parameter setup
;
REPEAT
LET @#KISAR3 := ZFSA ;;; Setup APR3 to map to buffer
LET R4 := (PC)+ ;;; Get load length
ZFLLEN: .WORD 498.-2 ;;; ?? was 3
LET (R5) := #DC.STA!DC.NIE
NOP
NOP
LET R5 := R5 + #P$STAT-P$CSR2
;
; controller basic loop
;
ZFLOOP:
.ASSUME CS.BSY EQ <^O200>
REPEAT UNTILB (R5) PL #0 AND #CS.DRD SET.IN (R5)
LET R0 :B= ZFBLKH+1 ;;; HIGH BYTE HIGH LBN - "TRACK"
LET R0 := R0 OFF.BY #^C<17> SET.BY #DH.PRM ;;; ONLY LOW 4 BITS PLUS FIXED BITS
LET P$DH-P$CMD(R5) :B= R0 ;;; "TRACK"+fixed bits
LET P$CYLH-P$CMD(R5) :B= ZFBLKH ;;; "HYGH CYLINDER" BYTE
LET P$CYLL-P$CMD(R5) :B= ZFBLKL+1 ;;; "LOW CYLINDER" BYTE
LET P$SNUM-P$CMD(R5) :B= ZFBLKL ;;; "SECTOR"
LET R1 := #255. ;;; MAX CHUNK
IF R1 HI R4 THEN ;;; MAX CHUNK LESS OR EQUAL REST LENGTH ?
LET R1 := R4 ;;; NO - REST OF IMAGE
END
LET (PC)+ := R1
ZFCHNK: .WORD 0
LET P$SCNT-P$CMD(R5) :B= R1 ;;; SECTOR COUNT
LET (R5) :B= (R3) ;;; Start the function
.REPT 5.
NOP
.ENDR
;
; Common transfer loop
;
COMMON:
;
; Perform silo/memory transfers - empty silo OR, fill silo before writing
;
LET R2 := R5 + #P$DBUF-P$CMD ;;; Copy CSR address, point to IDE data buffer
LET (PC)+ := ZFCHNK
ZFCNK2: .WORD 0
REPEAT
REPEAT
.ASSUME CS.BSY EQ <^O200>
REPEAT UNTILB #CS.RD EQ (R3) ORB (R5) PL #0
UNTIL #CS.DRQ SET.IN (R5)
IF #CS.ERR SET.IN (R5) GOTO ERR ;;; If error, try again
LET R1 := #60000 ;;; Set base for APR3 mapping
THRU R0 := #256. ;;; Set count of words in silo
MOVE:
LET (R1)+ := (R2) ;;; Empty silo (will change to fill silo)
END ;;; Loop until done
LET @#KISAR3 := @#KISAR3 + #10 ;;; Update APR3 mapping by 256. words
TST (PC)+ ;;; Is the NXM trap setup?
TRPFLG: .WORD 0 ;;; Flag=0 first time thru
IF RESULT IS EQ THEN
LET (PC)+ := @#4 ;;; Save current trap 4 vector
TRPPC: .WORD 0 ;;;
LET (PC)+ := @#6 ;;; ...
TRPPS: .WORD 0 ;;;
LET TRPFLG := TRPFLG + #1 ;;; Indicate that we have been here
LET @#6 := #PR7 ;;; Set new PS
LET R0 := PC + #<TRP4-.> ;;; Calculate trap address
LET @#4 := R0 ;;; Set new PC
END
LET ZFCNK2 := ZFCNK2 - #1
UNTIL RESULT IS EQ
TST (PC)+ ;;;
ERR:
SEC
UNTIL RESULT IS CC
LET ZFSA := @#KISAR3
LET R1 := ZFCHNK ;;; RESTORE CHUNK SIZE
LET ZFBLKL := ZFBLKL + R1 ;;; Update current LBN
LET ZFBLKH := ZFBLKH + CARRY
LET R4 := R4 - R1 ;;; ONE CHUNK LESS
LET ZFLLEN := R4 ;;; SAVE REST
IF RESULT IS HI GOTO ZFLOOP
GOTO ZFDONE
END $ZFDRV
;
; We are finished
;
PROCEDURE TRP4
BEGIN
$GOTO ZFDONE
END TRP4
PROCEDURE ZFDONE
BEGIN
LET @#4 := TRPPC ;;; Restore PC
LET @#6 := TRPPS ;;; Restore PS
LET R5 := R5 + #P$CSR2-P$STAT
;
; For virgin system
;
LET R0 := R5
LET R1 := (PC)+
BBLKH: .WORD 0 ;;; (HIGH) LBN of image
LET R2 := (PC)+
BBLKL: .WORD 0 ;;; (LOW) LBN of image
LET R3 :B= 1(R3) OFF.BY #^C<377> ;;; Get unit number
LET R4 := SZFNAM ;;; Get device name
LET R5 := (PC)+ ;;; Get device name
BLEN: .WORD 0 ;;; length of load file
;
; For SAVe
;
; LET R0 := R4 ;;; Get residual block count
; LET R1 := SZFNAM ;;; Get device name
; LET R4 :B= 1(R3) ;;; Get unit number
; LET R5 := R5 + #P$CSR2-P$STAT
LET @#KISAR3 := SKxSAR
;
; For virgin system
;
LET PC := #4672
LET PC := #65772
ZFEND:
;
; For SAVe
;
RETURN ;;; must be return and must be last
;;; instruction in ZF special driver
;;; (SAV assumed this is return
;;; and replace it in VBN 1,2,3 of
;;; SAVED IMAGE !!!!!
END ZFDONE
;
; Driver table
;
DRVS:
.ASCII /ZF/ ; ZF driver
.WORD ZFLLEN ; Address of load length
.WORD ZFSA ; Address of buffer address
.WORD SZFFUN ; Address of function code/unit
.WORD $ZFDRV ; Driver entry address
.WORD <ZFEND-$ZFDRV>/2 ; Size of driver in words
.WORD CS.WT ; Write function code
.WORD CS.RD ; Read function code
.WORD 0 ; Unit select bits
.WORD SZFFUN ; Address of function code word
.WORD SZFCSR ; Address of CSR address
PROCEDURE START
BEGIN
RESET
LET SP := #10000
LET R0 := #0
LET R1 := #BOOTZF
THRU R2 := #<ZFEND+2-BOOTZF>/2
LET (R0)+ := (R1)+
END
LET R0 := #1
LET R1 := #ZFBASE+P$CSR2
LET PC := #0
END START
END BOOTZF
.END START
Пример того, как может выглядеть программа на языке ассемблера. Используется СТАНДАРТНЫЙ Macro-11
- - - Добавлено - - -
Есть ядро, есть драйвера, есть задачи (task),
Забыл ещё про разделяемые библиотеки - аналог .dll - но с точки зрения системы - это области памяти с загруженными кодом и/или данными. Ещё один вариант (но уже достаточно экзотичный) использования разделяемой библиотеки - для доступа к (части) страницы в/в со стороны непривилегированных задач.
Lethargeek
09.02.2020, 16:11
Если бы вы покапали получше, та нашли бы, что этот пример было специально выбран, чтобы показать преимущество 68к по плотности кодов. Там адресные регистры используются как временная память, а у х86 регистров не хватает. Кстати, лучший полученный код для рисования линии для х86 - 81 байт. Код для Арма используют трудные трюки, а код для х86 - совсем пpостой. Другой пример, перевод числа в десятичный формат показал значительное преимущество х86.
сильно сомневаюсь, это который?
Код по затворному пи получился одинаковым по размеру (136 байт), но амигавцам для этого пришлось писать ненормальный код, использующий стек, который надо заранее для программы в системе выделить.
зато арм может столько "стеков" навыделять, насколько свободных регистров под указатели хватит :D
Но это всё частности, а тут сами армовцы конкретно признают code density is less so an application in RISC is likely to consume more memory than the equivalent in CISC
:v2_dizzy_facepalm: а до конца предложение дочитывать не судьба? полностью:
In addition, code density is less so an application in RISC is likely to consume more memory than the equivalent in CISC; however the ARM has a few tricks up its sleeve to reverse this assumption.
то есть армовец, напротив, ВОЗРАЖАЕТ против такого предположения
и такого можно найти ещё в весьма солидных источниках.
ага, "высочайший" уровень работы с источниками по предыдущему примеру уже понятен :v2_rolley
вот как можно после этого браться за исторические статьи? журнализм какой-то (в худшем смысле этого слова)
Повторю, "танк" с ДОСом или Виндузом нормально работал для сотен миллионов юзеров,
разве что каких-нибудь секретарш, которые никогда не запускали больше трёх с половиной софтин на них
в досе - постоянный трах с тремя кнопками, настройкой дополнительной памяти и подбором совместимых драйверов мыши
а для виндозов поначалу даже избегали писать топ-игры, пока характеристики железа не подросли
У Арм с регистрами всё в порядке, речь была именно о 68к. Регистров у 68000 столько же, сколько у х86,
еще раз, перечитывать до полного просветления:
у 68000 столько же РЕГИСТРОВ ДАННЫХ, сколько у 8086 регистров НЕ-СОВСЕМ-ОБЩЕГО НАЗНАЧЕНИЯ
и ПЛЮС к ним АДРЕСНЫЕ, то есть АДРЕСА НЕ ЗАНИМАЮТ РЕГИСТРЫ ДАННЫХ, В ОТЛИЧИЕ ОТ 8086
то есть по факту у 8086 в каждый момент времени меньше регистровой памяти под данные
(и это даже без учёта разрядности 16 против 32!)
Зато х86 имеет больше регистров, если работать с байтами.
если обрабатывать только байты, то у x86 те же 8 байтовых регистров и 4 небайтовых "адресных"
а у моторолы - 8 байтовых и 8 небайтовых адресных - иииии победа присуждается мотороле! :p
Наверное амиги и т.п. с 80286 - это было бы очень дорого, но с 80186 наверное получилось бы супер, не дороже, чем с 68000. 80186 был заметно дешевле и ненамного медленнее 80286.
ага, щяз, "ненамного" - это раза в полтора-два
А том и речь, что Интел всегда имела более дешевые аппаратные компоненты для своих процов.
да при чём тут интел и процовые компоненты? в рабочих станциях дорогие быстрые диски, память, видеокарты...
У них у всех цикл обращение к памяти был 4 такта. 80286 - 2, у Арма - 1.
Спасибо, отличнику! Но как он такой умный объяснит, что MOV из памяти выполняется на 80286 выпоняется всегда за 3 такта,
не "всегда", а "в лучшем случае" за три такта
Это верно, но сам-то 80286 или 80186 побыстрее 68000.
толку-то от сферобыстроты в вакууме? когда на практике даже в песюках дешёвых под вайтами бывал и медленней
В 80286 есть нормальный ммю и вы это знаете.
нет, я знаю, что для НОРМАЛЬНОГО не понадобилось бы потом срочно добавлять к нему еще и V86
На амигах не было никакого ммю и это вы знаете.
на поздних был, на остальных чипсет с многозадачностью справлялся почему-то лучше, чем "нормальный ммю 286"
А вот на Архимедах ммю ставили, но базовая система RiscOS так до сих пор (с ней продолжают работать - довольно неплохо смотрится на Пи с малиной) и осталась лишь условно многозадачной - там, например, при выходе в консоль, все процессы замирают.
насколько знаю, тому причиной не железо, а скорей недостаток человековремени у акорна (что потом уже сказалось и на железе)
Вы не поняли. Вам нужна маленькая программка, вы ее быстро набираете мнемониками и тут же сливаете на диск.
да ну, ересь, эффект будет сколько-нибудь заметным, если мне регулярно будет нужно сразу куча крохотных отдельных программок (не могу представить себе, зачем бы)
В общем, поскольку уровень господина-"эксперта" мне совершенно понятен, а свободное время не бесконечно, пошёл ка я лучше доделывать драйвер CF, а то ещё модуль Ethernet для Кванта-2020 заждался. Будет Ethernet - любой желающий сможет подключиться к Квант-у и посмотреть на программу, которая может использовать до трех с чем-то мб памяти на 16-ти битной машине с нормальным ДП и ОС. Кстати, заодно и на СОВЕТСКУЮ программу редактор-оболочку, которая примерно так года на год-полтора опередила по идеям NC. Жаль только, что первоначально была сделана версия под RSX, а не под RSX и RT
.SAV. Первый блок - некоторое количество ячеек со служебной информацией (типа - точка входа, начальное значение стека, размер загрузки) плюс свободные ячейки и место под стек (если по умолчанию, то начальное значение стека 1000(8)). Если специально не задавать значение стека и не играться абсолютными секциями, код и данные пойду с адреса 1000, и в .SAV файле это будет второй блок. То есть, если не принимать специальных мер, минимальный размер программы в RT - 2 блока. При тех же условиях в RSX - 4 блока (первые два - служебная информация).
889(10) байта - два блока - итого размер .SAV три блока или 512*3=1536 байт. Фраза выше говорит о полном не знании даже RT
Вот это уже интереснее. Имеем, как минимум, один блок загрузочной информации, а таких блоков в СОМ-файлe всегда ровно 0.
Аха. И применение на атомных станциях PDP говорит о полном Г среди современных контроллеров.На всех атомных станциях стоят ПДП-11 - это уже дигноз - обостренная пидипимания. :)
И я про тоже - полное не знание фактов.Не знаю про детали вашего Кванта. Где бы их мог получить? Рассказали бы. Для меня Квант, это что-то с ВМ4 и памятью метра на 2, минимум.
Текст "супер-программы" приведён вышеВас попросили имя файла в каталоге, чтобы виден был размер.
Потому что, в отличии от вас, я знаю - особенности системы команд PDP-11 и как работает Macro-11 и почему он не может "просчитать" простые переходыОт того, что вы знаете, почему что-то сделано плохо, оно от этого лучше не становится. Ну мастерп был пьян, скрипка не удалась, бывает. Но скрипка не удалась.
А в нормальных конторах работала многопользовательская RSX с памятью от мегабайта (например СМ-1420 или СМ-1600) и нормальной поддержкой программ, которым требуется немного больше памяти, чем 64 кб. Компиляторы с Fortran-а, кстати, генерировали код, который умел это дело.
Тут я с вами согласен, RSX-11 была самой продвинутой среди осей для пдп-11. Но тормозной, без каталогов (их вроде там как-то вроде и можно прикрутить, но почему-то обычно этого не делали). У нас вроде народ этим занимался, как побольше программы под пдп-11 делать и что-то получилось, но это типа редкого нестандарта - если бы это было не так, вы бы сразу назвали имена типичных файлов и их назначение. Компьютер BQT в открытом доступе и его RSX-11 может считаться эталонной. С другой стороны, абсолютное большинство людей, имевших дело с пдп-11 в СССР про RSX-11 почти ничего и не знал.
А в RSX и XM мониторе подход очень похожий, так что написать программу особого труда не составит. Кстати, опять же - компилятор с Fortran-а позволял писать программы, которым требовалось больше 64 кб, причём в наличии было два варианта библиотек поддержки - для программы, которая будет работать под XM монитором (по сути аналогичный подход, как и в RSX) или (внезапно) под SJ или FB, при условии, что проц PDP с MMU и размером памяти больше 56 кб
И где же такие программы среди стандартных? В ДОСе таких было много и даже большинство.
Пример того, как может выглядеть программа на языке ассемблера. Используется СТАНДАРТНЫЙ Macro-11
И что тут особенного? Любой нормальный макроассемблер так может. Больше использую fasm (для x86 и ARM) - там возможности для макросов, которых для макро-11 нет.
Забыл ещё про разделяемые библиотеки - аналог .dll - но с точки зрения системы - это области памяти с загруженными кодом и/или данными. Ещё один вариант (но уже достаточно экзотичный) использования разделяемой библиотеки - для доступа к (части) страницы в/в со стороны непривилегированных задач.
Ещё экзотичнее! А нормального файла с программой более 64 кб так и не представленно.
сильно сомневаюсь, это который?
68k
todec: ;converts d5 to stringbuf, it occupies 42 bytes
lea stringbuf(pc),a2
moveq #10,d1
.l1: move.l d5,d2
move.l d5,d0
clr.w d0
swap d0
divu d1,d0
swap d0
swap d2
move.w d0,d2
swap d2
divu d1,d0
move.w d2,d0
swap d2
or.b #'0',d2
move.b d2,(a2)+
move.l d0,d5
bne .l1
rts
x86
todec: ;convert dx:ax to stringbuf, it occupies 30 bytes
mov bx,stringbuf
mov si,10
.l1: mov cx,ax
mov ax,dx
xor dx,dx
div si
xchg ax,cx
div si
or dl,'0'
mov ,dl
inc bx
mov dx,cx
or cx,ax
jnz .l1
retn
Есть ещё код для 68000, использующий трюки со стеком, на 36 байт.
lea (stringbuf,pc),a2
moveq #10,d1
loop
move.l d5,-(a7) ; 0012 3456
moveq #0,d5
move.w (a7)+,d5 ; 0000 0012
divu.w d1,d5 ; 0008 0001
move.l d5,d0
move.w (a7)+,d5 ; 0008 3456
divu.w d1,d5 ; 0006 d208
swap d5 ; d208 0006
or.b #'0',d5
move.b d5,(a2)+
move.w d0,d5 ; d208 0001
swap d5 ; 0001 d208
bne.b loop
rts
зато арм может столько "стеков" навыделять, насколько свободных регистров под указатели хватит :DОпять вы сбились, текст был про амиги, а там 68к и регистр стека один (два точнее, но второй пользователю недоступен). Этот трюк у амиговцев и получился только потому, что у 68к системный стек отдельный, на х86 так бы не получилось, там прерывания могли бы попортить данные.
:v2_dizzy_facepalm: а до конца предложение дочитывать не судьба? полностью:
то есть армовец, напротив, ВОЗРАЖАЕТ против такого предположения
Что там не дочитано? Там написано, что да, хуже, но у нас есть трюки. Типа да ваше авто быстрее нашей лошадки, но лошадка может и по полю проскакать диагональю. :) Тема плотности кода - непростая. На одних задачах одно лучше, на других другой. Но код Арма без пальца побольше х86 практически всегда. Вот, например, ссылка (http://web.eece.maine.edu/~vweaver/papers/iccd09/ll_document.pdf).
ага, "высочайший" уровень работы с источниками по предыдущему примеру уже понятен :v2_rolley
вот как можно после этого браться за исторические статьи? журнализм какой-то (в худшем смысле этого слова)
Какие исторические статьи? Может проблема в том, что люди, которые хорошо знают Арм (англичане-энтузиасты) никогда не сомневались при общении со мной (а они мою статью про АРМ читали), что плотность кодов у АРМа пониже. Хотя, Арм-Палец нередко позволяет обогнать х86 по плотности, но, повторю, ценой тормозов. Но это уже не старый добрый британский Арм, а то что из него сделали.
разве что каких-нибудь секретарш, которые никогда не запускали больше трёх с половиной софтин на них
в досе - постоянный трах с тремя кнопками, настройкой дополнительной памяти и подбором совместимых драйверов мыши
а для виндозов поначалу даже избегали писать топ-игры, пока характеристики железа не подрослиВы работали с секретаршами? Если у них что-то падает, то будет истерика, а они работали и без истерик. А Дум откуда взялся, который Амиги закрыл? А Квейк, Цивилизация и почти все топовые игры до конца 90-х? Ерунду пишите.
еще раз, перечитывать до полного просветления:
у 68000 столько же РЕГИСТРОВ ДАННЫХ, сколько у 8086 регистров НЕ-СОВСЕМ-ОБЩЕГО НАЗНАЧЕНИЯ
и ПЛЮС к ним АДРЕСНЫЕ, то есть АДРЕСА НЕ ЗАНИМАЮТ РЕГИСТРЫ ДАННЫХ, В ОТЛИЧИЕ ОТ 8086
то есть[B] по факту у 8086 в каждый момент времени меньше регистровой памяти под данные
(и это даже без учёта разрядности 16 против 32!)
если обрабатывать только байты, то у x86 те же 8 байтовых регистров и 4 небайтовых "адресных"
а у моторолы - 8 байтовых и 8 небайтовых адресных - иииии победа присуждается мотороле! :p
Разрядность у 68000 адреса только 24 бита, а с данными по 32-бита работа идет очень медленно. У х86 роль адресных играют сегментные регистры, а в 68000 вам нужно постоянно и ЯВНО прописывать базовый адресный регистр. Если вам нужна индексация, то двойных индексов, как в х86, у 68к нет вообще, так как один из регистров - это база. Поэтому возня с адресными регистрами на 68к неприятный сюрприз для знакомых с х86 архитектурой.
Для байтов у 8086 8 нормальных байтовых регистров и ещё три для пар байт, у 68000 8-байтовых регистров и 8 адресных регистров, которые использовать для работы с данными непросто. Как пары байт их использовать не получится точно и байты в них грузить нельзя. Проверьте свою арифметику.
не "всегда", а "в лучшем случае" за три тактаВот вам ещё, отличникам, пример. Инструкция MOVS выполняется за 5 тактов: 2 на прием из памяти, 2 на запись и 1 на саму инструкцию - два регистра надо изменить. В MOV та же история, 1 такт на саму инструкцию, 2 два на память.
толку-то от сферобыстроты в вакууме? когда на практике даже в песюках дешёвых под вайтами бывал и медленней
Не понял фразы. :(
нет, я знаю, что для НОРМАЛЬНОГО не понадобилось бы потом срочно добавлять к нему еще и V86Дос хорошо пошел, вот и добавили поддержку. Для нормальнольного мультитаскинга в 80286 все было отлично, не хуже лучших ПДП-11, а скорее лучше.
на поздних был, на остальных чипсет с многозадачностью справлялся почему-то лучше, чем "нормальный ммю 286"Какая на Амигах многозадачность - простейшая, как и на первых виндузах. И Доса на амигах не было, а это и было главной проблемой на х86. Зиникс очень надежная система, с правильной архитектурой, но народ на Дос подсел.
да ну, ересь, эффект будет сколько-нибудь заметным, если мне регулярно будет нужно сразу куча крохотных отдельных программок (не могу представить себе, зачем бы)Речь идет только о маленьком удобстве. Ещё пример, кэш включить, выключить и т.п.
В общем, поскольку уровень господина-"эксперта" мне совершенно понятен, а свободное время не бесконечно, пошёл ка я лучше доделывать драйвер CF, а то ещё модуль Ethernet для Кванта-2020 заждался. Будет Ethernet - любой желающий сможет подключиться к Квант-у и посмотреть на программу, которая может использовать до трех с чем-то мб памяти на 16-ти битной машине с нормальным ДП и ОС. Кстати, заодно и на СОВЕТСКУЮ программу редактор-оболочку, которая примерно так года на год-полтора опередила по идеям NC. Жаль только, что первоначально была сделана версия под RSX, а не под RSX и RT
А почему эксперта? Кто так меня вам представил так без меня? Лишь собираю данные. Правильно и вежливо ко мне обращаться надо - господин архивариус. Успехов в ретро-программировании. Некоторые такие крутые программы написали, что в 80-е и присниться немогло. И ещё не все шедевры прошлых лет найдены. Завел в Корветах тему про Турбо-Паскаль 4 для 8080 - работал лучше, чем Турбо-Паскаль 3 для z80 и даже 8088. И даже чем-то вроде обходил 4 на 8088! Но сорсов до сих пор нет. Автор хотел заработать... А ведь шедевр получился, хотя сам не тестировал - может там и багов вагон.
HardWareMan
09.02.2020, 20:03
Спасибо, отличнику! Но как он такой умный объяснит, что MOV из памяти выполняется на 80286 выпоняется всегда за 3 такта, а на 68030 за от 5 до 42 (если повезет с кэшем, то от 3 до 30).
Если один раз понять, чем отличаются CLK от PROC CLK и почему последний фигурирует в маркетинговых флаерах то вся магия растворяется. Повторюсь: продолжайте прогуливать физику и ваша жизнь наполнится чудесами и магией.
Вот это уже интереснее. Имеем, как минимум, один блок загрузочной информации, а таких блоков в СОМ-файлe всегда ровно 0.
Это не блок загрузочный информации. .SAV - образ памяти. Памяти в PDP начинается с адреса 0. Если тупо грузануть с адреса 0 - затрутся вектора и служебные ячейку. Так что загрузка пойдёт с адреса 1000, а это блок номер 2.
Вас попросили имя файла в каталоге, чтобы виден был размер.
RSX-11 была самой продвинутой среди осей для пдп-11. Но тормозной, без каталогов (их вроде там как-то вроде и можно прикрутить, но почему-то обычно этого не делали).
С другой стороны, абсолютное большинство людей, имевших дело с пдп-11 в СССР про RSX-11 почти ничего и не знал.
MCR > DIR DU1:[MACPROG]BIGPRG.TSK
Directory DU1:[MACPROG]
2020-02-09 20:53
BIGPRG.TSK;1 4. C 2020-02-09 13:45
Total of 4./4. blocks in 1. file
MCR > DIR DU:[3,54]DCL.TSK
Directory DU0:[3,54]
2020-02-09 20:56
DCL.TSK;2 442. C 2017-07-19 13:30
Total of 442./442. blocks in 1. file
MCR >
Моя программа была написана как пример. Она во время выполнения расширяет доступную себе память, запрашивая у системы 2 мбайта и приостанавливает своё выполнение. Пример программы, которая использует больше 64 кб - BRU, второй пример выше. Так же в листингах выше - те самые каталоги, которых у вас отчего то в rsx не было и которые надо было как то прикручивать - то есть полное незнание rsx
И где же такие программы среди стандартных? В ДОСе таких было много и даже большинство.
А стандартные писались так, что бы они занимали как можно меньше памяти (даже ценой оверлеев), потому что в те времена цена памяти была запредельной. Из документации:
The RSX-11M Realtime Operating System can be used on any DEC PDP-11 computer(*) ....
---------
(*) The minimum configuration is a 16K PDP-11/10 with a Teletype (Teletype is a registered trademark of the Teletype Corporation) or LA30 for the console terminal; one RK disk drive? which is the system distribution medium; a KW11-L/P for the system clock; a hardware bootstrap loader, and either one additional RK disk drive, a DECtape or cassete.
16кб. А не как сейчас - 16 Гб ещё и мало будет. Поэтому и была написана RT-11 для машин с минимальным размером памяти. И если посмотреть на то, что сейчас есть в наличии из PDP совместимого - больше всего БК, УК-НЦ, 1201.01, 1201.02 - все без ДП и с макс размером памяти соответственно - 56кб
В 84-ом году, когда на лаборатории на химфаке МГУ сменили СМ-3 на СМ-4 с 248 кб памяти, первое что мы тогда сделали - поставили RSX. И везде в МГУ - если на машине было ДП и памяти больше 64 кб - доставали и ставили RSX. Где бы не работал позже - или ОС-РВ или (при возможности) ставили RSX
Так что
С другой стороны, абсолютное большинство людей, имевших дело с пдп-11 в СССР про RSX-11 почти ничего и не знал.
полная хрень.
А нормального файла с программой более 64 кб так и не представленно.
Ну да, "специалист" даже непонял
Не знаю про детали вашего Кванта.
Ну это очевидно и так
Где бы их мог получить?
В интернете, вестимо
Рассказали бы. Для меня Квант, это что-то с ВМ4 и памятью метра на 2, минимум.
Вот пусть этим и остаётся
Правильно и вежливо ко мне обращаться надо - господин архивариус.
Для начала - заслужить это надо. Но когда человек порет чушь от незнания предмета...
Я закончил, больше общаться желания нет от слова совсем.
Если один раз понять, чем отличаются CLK от PROC CLK и почему последний фигурирует в маркетинговых флаерах то вся магия растворяется. Повторюсь: продолжайте прогуливать физику и ваша жизнь наполнится чудесами и магией.
Писал про реальное быстродействие, которое этими тактами просчитывается. Вы не ответили на вопрос, отличник! Похоже и вам двойка. Нет тут отличников. :(
Это не блок загрузочный информации. .SAV - образ памяти. Памяти в PDP начинается с адреса 0. Если тупо грузануть с адреса 0 - затрутся вектора и служебные ячейку. Так что загрузка пойдёт с адреса 1000, а это блок номер 2.
А почему бы не грузить сразу с адреса 1000 как СОМа с 800? Называйте как хотите, но 512 или больше байт имеем на системные нужды. Типичная загрузочная информация.
Моя программа была написана как пример. Она во время выполнения расширяет доступную себе память, запрашивая у системы 2 мбайта и приостанавливает своё выполнение. Пример программы, которая использует больше 64 кб - BRU, второй пример выше. Так же в листингах выше - те самые каталоги, которых у вас отчего то в rsx не было и которые надо было как то прикручивать - то есть полное незнание rsx
Спасибо, уважаемый. А почему вы решили, что у меня какое-то знание особенно большое про RSX-11? У меня есть некоторая информация и интерес к некоторым деталям - всё. Сказать полное незнание нельзя - у меня есть программки для RSX-11 и небольшой опыт работы. А теперь по делу. Не могли бы помочь понять, а как RSX-11 позволяет прикладной программе работать с памятью большей 64 кб? Адреса 16-битные, а базовые адреса - это системный ресурс. И ещё, уважаемый эксперт, насчет каталогов. Сталкивался с тем, что в RSX-11 были каталоги только первого уровня, но не было второго, который должен прикручиваться отдельно - вы как эксперт должны знать о таком - в ваших примерах вложенных каталогов не нашёл - подскажите, пожалуйста, где, если пропустил.
А стандартные писались так, что бы они занимали как можно меньше памяти (даже ценой оверлеев), потому что в те времена цена памяти была запредельной. Из документации:
The RSX-11M Realtime Operating System can be used on any DEC PDP-11 computer(*) ....
---------
(*) The minimum configuration is a 16K PDP-11/10 with a Teletype (Teletype is a registered trademark of the Teletype Corporation) or LA30 for the console terminal; one RK disk drive? which is the system distribution medium; a KW11-L/P for the system clock; a hardware bootstrap loader, and either one additional RK disk drive, a DECtape or cassete.
16кб. А не как сейчас - 16 Гб ещё и мало будет. Поэтому и была написана RT-11 для машин с минимальным размером памяти. И если посмотреть на то, что сейчас есть в наличии из PDP совместимого - больше всего БК, УК-НЦ, 1201.01, 1201.02 - все без ДП и с макс размером памяти соответственно - 56кб
На ПДП-11 с с середины 80-х ставили много памяти - системки недешёвые, ставили её немало и раньше на мини-менфреймы с Юникс и, возможно, с RSX-11. Ho юзер получал только менее 64 кб. Не понятно, что тут спорить. Большие коды поддерживались только каким-то шаманством.
В 84-ом году, когда на лаборатории на химфаке МГУ сменили СМ-3 на СМ-4 с 248 кб памяти, первое что мы тогда сделали - поставили RSX. И везде в МГУ - если на машине было ДП и памяти больше 64 кб - доставали и ставили RSX. Где бы не работал позже - или ОС-РВ или (при возможности) ставили RSX
Так что полная хрень.
А химфак - это весь Союз? Даже не смешно. У меня знакомые с Демосом работали, тут на форуме люди в основном про RT-11. Тоже в МГУ работал, но на физфаке, знаю людей из лаборатории DEC, что работали там в 90-е, но это уже была эра Альфа.
В интернете, вестимо
Вот нашел.
ДВК-4М
На основе «Электроника МС 1201.04». Имеет память размером 1 МБ, которая могла использоваться как RAM-диск.
Было выпущено несколько компьютеров с сопроцессором плавающей точки К1801ВМ4. На части компьютеров стояла ОС ДЕМОС-ДВК. Продвинутые пользователи ставили вместо неё RT11-SJ («Single Job» — однозадачную ОС от PDP-11) или RT11-FB (многозадачная), RT11-XM («eXtended Memory» — расширенная память), RT11-CD (система для УКНЦ), Фодос — по сути кривой перевод на русский с этих ОС.
Квант-4С
Комплектация аналогична ДВК-4М, но комплекс смонтирован в горизонтальном металлическом корпусе.
Вот пусть этим и остаётсяПонятно, что ВМ3 и опциональный ВМ4. Что не так? Чем опять "эксперт-специалист" вам, истинному эксперту, не угодил? Но нашел ещё ссылку (https://radikal.ru/fp/c90af1704b2b4a16a6f62391ca2cca03) - такой у вас? Там цена почти 20000 руб. Года нет. :( Неужели 1987? Обсуждающий народ считает, что это покруче ЕС-1841 - согласен.
Для начала - заслужить это надо. Но когда человек порет чушь от незнания предмета...Ничего я вам не порю, а спрашиваю вас как специалиста-эксперта. Терплю ваши г. и прочие словестные выходки - а вы же в МГУ работали и не слесарем.
512 или больше байт имеем на системные нужды. Типичная загрузочная информация.
Образ памяти. Место под стек нужно? По умолчанию - с адреса 1000, то есть резервируется (по умолчанию) в блоке 1. Стек изначально пустой - зачем его грузить. Вектора прерываний используются в работе. Их грузить из .sav и затирать рабочие? Поэтому прочитали блок 1, получили инфу о стеке, о точке входа, сколько блоков грузить. Дальше один запрос на чтение и передача управления. Где речь идёт о таблице релокации и правке в памяти загруженного, как в .exe?
А почему вы решили, что у меня какое-то знание особенно большое про RSX-11? У меня есть некоторая информация и интерес к некоторым деталям - всё.
Тогда не несите чушь и слушайте, что говорят те, кто работает с RSX с 84-ого года.
Не могли бы помочь понять, а как RSX-11 позволяет прикладной программе работать с памятью большей 64 кб? Адреса 16-битные, а базовые адреса - это системный ресурс.
Запросы к ядру
Сталкивался с тем, что в RSX-11 были каталоги только первого уровня, но не было второго, который должен прикручиваться отдельно
Вообще то первый уровень - это каталог [0,0]. Рабочие каталоги - это уже второй уровень. Файловая система ODS-1. Третий уровень делали в P/OS. Поддержка третьего и дальше уровней штатно - ODS-2 и выше. Не могу сказать точно, почему не сделали, но судя по тому что я виде в исходниках VMS - это слишком ресурсно-затратно для тех времён. Хотя у меня есть мысль - добавить это дело на современных процессорах PDP-11
А химфак - это весь Союз? Даже не смешно
А я не только на химфаке работал.
тут на форуме люди в основном про RT-11
Тут на форуме у людей в основном БК и УК-НЦ
Вот нашел.
Продвинутые пользователи ставили вместо неё RT11
Продвинутый пользователь перенес на неё RSX примерно лет за 10 до того, как на этом форуме поднялся вопрос (и долго муссировался), что RSX на ВМ3 не заработает, потому что в нём ошибки. Хорошо, что я примерно так в 91-92 годах об этом не подозревал и просто перенёс.
спрашиваю вас как специалиста-эксперта.
Вы не спрашиваете. Вы утверждаете вещи, в которых не разбираетесь, по вашему же признанию
А почему вы решили, что у меня какое-то знание особенно большое про RSX-11?
а вы же в МГУ работали и не слесарем.
Аха. В 19 лет. И не слесарем.
Lethargeek
10.02.2020, 03:08
todec: ;convert dx:ax to stringbuf, it occupies 30 bytes
mov bx,stringbuf
mov si,10
.l1: mov cx,ax
mov ax,dx
xor dx,dx
div si
xchg ax,cx
div si
or dl,'0'
mov [bx],dl
inc bx
mov dx,cx
or cx,ax
jnz .l1
retn
странная какая конверсия в перевёрнутую строку, но ладно уж
только по-честному вместо mov для загрузки адреса буфера надо бы использовать lds
да и параметры в регистры dx:ax тоже как-то попадают сперва из памяти
но самое смешное, что код arm2, оптимизированный на скорость (~18 тактов на итерацию!) занимает не так чтобы очень много - 56 байт
а если вызывать деление процедурой (каковая всё равно еще где-нибудь в большой программе будет нужна) - только 20 байт :v2_dizzy_roll:
Опять вы сбились, текст был про амиги, а там 68к и регистр стека один
не "опять", потому что первым с арма на амиги сбился не я
Что там не дочитано? Там написано, что да, хуже, но у нас есть трюки.
не-не-не, ничего такого там НЕ написано! :v2_dizzy_stop: первая часть:
In addition, code density is less so an application in RISC is likely to consume more memory than the equivalent in CISC;
...говорит о неких абстрактных "рисках", а вторая:
however the ARM has a few tricks up its sleeve to reverse this assumption.
...говорит о том, что конкретно арм способен ОПРОВЕРГНУТЬ (дословно: "перевернуть") это предположение!
Но код Арма без пальца побольше х86 практически всегда. Вот, например, ссылка.
это ссылка на исследование качества компиляторов 2010-х годов, причём после долгих лет застоя на поле арма
Какие исторические статьи? Может проблема в том, что люди, которые хорошо знают Арм (англичане-энтузиасты) никогда не сомневались при общении со мной (а они мою статью про АРМ читали), что плотность кодов у АРМа пониже
сомневаюсь, что все поголовно не сомневались, почитав, как реагировали амижники :v2_laugh:
Хотя, Арм-Палец нередко позволяет обогнать х86 по плотности, но, повторю, ценой тормозов. Но это уже не старый добрый британский Арм, а то что из него сделали.
это то, что сделали ради мобильного рынка, где преобладали 16-битные шины, и на самом деле вовсе не для плотности, а для скорости
Вы работали с секретаршами? Если у них что-то падает, то будет истерика, а они работали и без истерик.
значит, я работал с неистеричными (а если что-то падало, выяснялось, что причиной была всунутая дискетка с посторонним софтом)
А Дум откуда взялся, который Амиги закрыл?
к тому времени амиги прекрасно закрывались самостоятельно в результате "эффективного менеджмента"
Разрядность у 68000 адреса только 24 бита, а с данными по 32-бита работа идет очень медленно. У х86 роль адресных играют сегментные регистры,
нетушки, только половину этой роли они играют
а в 68000 вам нужно постоянно и ЯВНО прописывать базовый адресный регистр. Если вам нужна индексация, то двойных индексов, как в х86, у 68к нет вообще, так как один из регистров - это база. Поэтому возня с адресными регистрами на 68к неприятный сюрприз для знакомых с х86 архитектурой.
вообще для знакомых с x86 архитектурой возня привычна, потому что программирование x86 - это и есть постоянная возня со ВСЕМИ регистрами :v2_lol:
Для байтов у 8086 8 нормальных байтовых регистров и ещё три для пар байт,
так, стопэ, а байты откуда брать? как без адресных регистров читать из памяти?
у 68000 8-байтовых регистров и 8 адресных регистров, которые использовать для работы с данными непросто.
как будто "пары байт" x86 для работы с байтами использовать очень просто - в основном обмен и временное хранение
но обмены есть и в 68000 - половинок регистров данных и целых регистров, включая адресные
что примерно так же можно применять для работы с байтами - и сколько тогда байтовой регистровой памяти?
Как пары байт их использовать не получится точно и байты в них грузить нельзя.
почему это нельзя? из регистров данных можно грузить; и в арифметике и логике применять как байты-источники
Не понял фразы.
для понимания погуглить таблицы dhrystone тестов и подивиться на разброс результатов
Дос хорошо пошел, вот и добавили поддержку. Для нормальнольного мультитаскинга в 80286 все было отлично,
ага, нормальный такой мультитаскинг, при котором over 95% наличного софта не работает, всё отлично :v2_clapp:
Какая на Амигах многозадачность -
- наблюдаемая в объективной реальности over 95% амижных юзеров
Речь идет только о маленьком удобстве. Ещё пример, кэш включить, выключить и т.п.
выключалку нужно написать один раз
На ПДП-11 с с середины 80-х ставили много памяти - системки недешёвые, ставили её немало и раньше на мини-менфреймы с Юникс и, возможно, с RSX-11. Ho юзер получал только менее 64 кб. Не понятно, что тут спорить. Большие коды поддерживались только каким-то шаманством.
А ничего, что первая RSX вышла в 74 году? Или тогда тоже ставили "много" памяти?
Ho юзер получал только менее 64 кб
Для XM монитора и RSX с поддержкой ДП - полная хрень - доказано выше.
Большие коды поддерживались только каким-то шаманством.
Ещё одна полная хрень. Для RSX и XM монитора RT - отлично документировано и достаточно легко используется. Причём можно насчитать аж три подхода.
- прямая работа с соответствующими запросами к ядру системы
- непрямая работа - оверлеи, резидентные в памяти - в RSX. Вроде что то подобные было и в XM мониторе, но учитывая его убогую многозадачность, я RT практически не использую, поэтому сходу не могу не подтвердить, не опровергнутью
- массивы Virtual (теоретически - только под данные, но мы в своё время научились хитрить, но не получив от этого никакой пользы - для кода вернулись к пункту 2
Для нахватавшихся знаний из мутных статей в инете, а не из официальной документации или личного опыта - пусть остаётся "только каким-то шаманством".
Хотя да, поскольку создатели Unix поделок шли каким-то своим тёмным путём - возможно, в Unix это так и осталось тёмным шаманством.
HardWareMan
10.02.2020, 07:10
Писал про реальное быстродействие, которое этими тактами просчитывается. Вы не ответили на вопрос, отличник! Похоже и вам двойка. Нет тут отличников. :(
36 лет назад, когда я был в первом классе, за мной уже закрепляли двоечника. И уже тогда я понял - нельзя двоечников вытягивать, им это не надо. Более того, их надо сразу в профкласс и на урановые рудники. Так пользы больше и государство сэкономит большие деньги. Это моё личное мнение.
Далее, вот ты писал:
Спасибо, отличнику! Но как он такой умный объяснит, что MOV из памяти выполняется на 80286 выпоняется всегда за 3 такта, а на 68030 за от 5 до 42 (если повезет с кэшем, то от 3 до 30).
https://jpegshare.net/images/85/8b/858b43d8089bff1acc03c1188befcdf5.png
Оказывается, что не всегда 3, верно?
https://jpegshare.net/images/a6/21/a621f8e2d59386581b50e1cbea1a3aeb.png
Т.е., эти самые CLK, указанные рядом с инструкцией, на самом деле PROC CLK, про который я говорил здесь (https://zx-pk.ru/threads/31307-pro-motorola-ibm-dec.html?p=1045128&viewfull=1#post1045128). И это внутренняя частота, которая является /2 от внешней, настоящей CLK. Таким образом, PROC CLK по сути тактовая частота шины, можно приравнять по смыслу к частоте того же M6502, который каждый такт делает обращение к шине. Но при этом, процессор 80286 работает на удвоенной частоте, в отличии от 6502. А раз так, то 3 шинных цикла вполне логично для команды, работающей с памятью. И теперь абсолютно понятно, почему в маркетинге любят PROC CLK а не CLK: проц по факту работает на удвоенной частоте, FIFO PIPLINE у 286 еще с 8086 остался, так что занизим заявленную частоту, чтобы в датащитах красиво смотрелись тайминги по сравнению с конкурентами.
Моторолла, кстати, оперирует не тактами а состояниями.
https://jpegshare.net/images/7c/03/7c03a69208f3eb8f302956028d89e565.png
При этом, тайминги инструкций указаны именно в периодах (тактах) честной внешней частоты в обоих режимах:
https://jpegshare.net/images/73/5a/735ac466dd77f9f9ecd88ab3caffef49.png
https://jpegshare.net/images/8e/0d/8e0d7e5a668d5860489c7ed665b3aac1.png
Что вполне логично выливается в +4 такта на каждое обращение к шине:
https://jpegshare.net/images/79/2d/792d3461dabbee7c5d95a8ef30212162.png
https://jpegshare.net/images/1c/36/1c36cc697c2f21d59aa2f5bf6d73ec6f.png
Так что для прямого сравнения 286 и 68000 надо либо умножать такты на 2 у первого, либо делить на 4 у второго.
Шах и мат. Теперь я буду только читать твои потуги под попкорн.
непрямая работа - оверлеи, резидентные в памяти - в RSX. Вроде что то подобные было и в XM монитореПодтверждаю. ХМ-монитор вполне поддерживает оверлеи, резидентные в верхней памяти. И остальные два подхода тоже. Более того, не удивлюсь, если узнаю, что эти три подхода впервые были сочинены для ХМ, а в RSX перенесены. Хотя, скорее всего, над этим работали параллельно: группа разработки ДП сочинила и выдала рекомендации, а группы разработки ОС эти рекомендации воплотили.
учитывая его убогую многозадачность, я RT практически не используюЕсть еще и TSX-11, у которой многозадачность нормальная - на каждом рабочем месте юзер может считать, что у него главная консоль RT-11XM - все ХМ-ные фенечки поддерживаются, кроме той самой убогой ХМ-ной многозадачности, которая в нормальной многозадачной ОС и даром не нужна (вроде-бы, точно не помню, ни разу ей не интересовался в силу ее убогости). Правда, TSX-11 не DEC-овская разработка, но MS-DOS тоже не межделмашевская. Родная ОС от IBM - OS/2 - увы, не состоялась.
-------------------------------------------
А вообще, как сказал Говорящий Клоп, "все это - хорошо оплачиваемый вздор, а на самом деле Вселенная имеет форму пружинного матраса".
Те, кто в курсе, не спорят, что по состоянию на начало 80-х PDP-11 была лучшей 16-разрядной машинкой, и "феномен IBM PC" имел место быть только потому, что руководство и IBM, и DEC относились к самой идее персонального компьютера с глубочайшим презрением. Мол, модные игрушки, мода пройдет, а наши изделия останутся...
А тема началась с моего заявления, что 68000 не состоялся потому, что не он был выбран Межделмашем в ЦП для писюка. Все тут же полезли в детали, с пеной у рта доказывая, что интелёвые процессоры лучше - быстрее, удобнее для программирования и т.п. Забывая о том, что 68000 надо сравнивать не с 80386, и даже не с 80286, а с 8088 (не 86!). Именно между ними стоял выбор у Межделмаша.
А дальше - дело в конкуренции. На рынке писюков конкуренция была высочайшей, мамаши для них клепали все, кому было не лень, процессоры тоже, как минимум, 3 производителя. Неудивительно, что параметры и процессоров и компьютеров на них росли, как на дрожжах, и цены падали до бросовых. Напротив, и 68000 делали одни мотороллеры, и клонмейкеров для компов на них, практически не было - те же надгрызенные жестко запатентовали все свои разработки и клонмейкерства не допускали. И, как результат, сдулись полностью, сейчас их Мак - это разновидность писюка. Равно, как и мотороллеры - нет процессоров 680х0, где-то в контроллерах они еще применяются иногда, а так, увы...
Есть еще и TSX-11, у которой многозадачность нормальная
Но не файловая система. Поэтому, поигравшись в своё время с TSX на Кванте (память упорно грызёт, что при более менее активной работой с диском отзывчивость системы была хуже, чем у RSX. Возможно, ошибаюсь), я перенёс RSX-11M-Plus 4.0 и дальше все варианты игр с RT были с флопов.
Напротив, и 68000 делали одни мотороллеры, и клонмейкеров для компов на них, практически не было - те же надгрызенные жестко запатентовали все свои разработки и клонмейкерства не допускали.
На самом деле, ровно такая же ситуация и у DEC - там вроде даже по лицензии то ли нельзя было делать, то ли с большими сложностями. Ну и как монополист, DEC, соответственно, "несколько" завышала цены
yuriy_sazonov
11.02.2020, 10:56
Доброго !
... процессоры тоже, как минимум, 3 производителя. Неудивительно, что параметры и процессоров и компьютеров на них росли, как на дрожжах, и цены падали до бросовых. Напротив, и 68000 делали одни мотороллеры, и клонмейкеров для компов на них, практически не было ...
Ну не... мотороллеров тоже выпускалось разными производителями много. На достаточно известном сайте можно посмотреть, даже с картинками www.cpu-world.com (http://www.cpu-world.com/CPUs/68000/index.html) без этого как-то не полно...
В одном из компьютеров (которые есть у меня) производства 1986г. стоит чип от Signetics ;)
интелёвые процессоры лучше - .... удобнее для программирования
И даже сейчас это - полная хрень :)
- - - Добавлено - - -
А вот макро-11 даже просчитать сдвинутый переход вперед не может - все известные мне ассемблеры для х86 и других систем могут.
И вперёд и назад
[* КОНЕЦ СТРАНИЦЫ *]
1 .TITLE SH
2 .MCALL EXIT$S
3 .ENABL LSB
4 000000 START:
5 000000 000421 BR 20$
6 000002 .BLKW 10
7 000022 10$:
8 000022 000421 BR 30$
9 000024 .BLKW 10
10 000044 20$:
11 000044 000766 BR 10$
12 000046 .BLKW 10
13 000066 30$:
14 000066 EXIT$S
15 000000' .END START
[* КОНЕЦ СТРАНИЦЫ *]
Symbol table
START 000000R
. ABS. 000000 000 (RW,I,GBL,ABS,OVR)
000074 001 (RW,I,LCL,REL,CON)
Errors detected: 0
*** Assembler statistics
Work file reads: 0
Work file writes: 0
Size of work file: 201 Words ( 1 Pages)
Size of core pool: 13506 Words ( 51 Pages)
Operating system: RSX-11M/M-PLUS
Elapsed time: 00:00:00.01
SH;1,TMP;1/-SP/NL:TTM=SH
[* КОНЕЦ ТЕКСТА *]
Ну не... мотороллеров тоже выпускалось разными производителями много.Поразглядывал картинки и почитал к ним описания. Очень похоже, что это произведено по лицензии от Моторолы, по широко применяемой в то время программе вторых поставщиков. А не самостоятельные изделия "по мотивам", как это было у АМД и Cyrix. Но, по-любому, спрос на интелёвые и совместимые с ними процессоры был намного больше, чем на мотороллеры, соответственно, они и развивались заметно быстрее. И, в итоге, 680х0 банально сдулись, нет их...
На самом деле, ровно такая же ситуация и у DEC - там вроде даже по лицензии то ли нельзя было делать, то ли с большими сложностями. Ну и как монополист, DEC, соответственно, "несколько" завышала ценыВот-вот, и я о том же. Зажрались, зажирели, и, в итоге, пролетели. Очередной повод задуматься на тему: вред наносит пиратство, или пользу? То есть да, владельцу авторских (или каких там еще) прав, пиратство - чистый убыток, а вот рядовому юзеру - только плюс, и сейчас, и в перспективе. Мораль - бей копирастов! :)
И даже сейчас это - полная хреньТак вестимо! Конфетку из говна, конечно, сделать можно, только вот запах... :)
36 лет назад, когда я был в первом классе, за мной уже закрепляли двоечника. И уже тогда я понял - нельзя двоечников вытягивать, им это не надо. Более того, их надо сразу в профкласс и на урановые рудники. Так пользы больше и государство сэкономит большие деньги. Это моё личное мнение.
Типа употребили хорошо крепленного пивка и мысли светлые пошли?
[Посмотрим в букварь]
Оказывается, что не всегда 3, верно?
Ну описался чуть-чуть. Робот бы сказал 3 такта занимают команды записи и 5 чтения. Человек в непринужденной беседе может и слегка сбиться. Однако, как уже писал уважаемому Lethargeek, команда MOVS занимает 5 тактов, а это чтение из памяти, запись в память, работа с индексными регистрами, ...
[А потом заглянем туда, куда двоечники никогда не смотрят]
Т.е., эти самые CLK, указанные рядом с инструкцией, на самом деле PROC CLK, про который я говорил здесь (https://zx-pk.ru/threads/31307-pro-motorola-ibm-dec.html?p=1045128&viewfull=1#post1045128). И это внутренняя частота, которая является /2 от внешней, настоящей CLK. Таким образом, PROC CLK по сути тактовая частота шины, можно приравнять по смыслу к частоте того же M6502, который каждый такт делает обращение к шине. Но при этом, процессор 80286 работает на удвоенной частоте, в отличии от 6502. А раз так, то 3 шинных цикла вполне логично для команды, работающей с памятью. И теперь абсолютно понятно, почему в маркетинге любят PROC CLK а не CLK: проц по факту работает на удвоенной частоте, FIFO PIPLINE у 286 еще с 8086 остался, так что занизим заявленную частоту, чтобы в датащитах красиво смотрелись тайминги по сравнению с конкурентами.
Моторолла, кстати, оперирует не тактами а состояниями.
Начало интересное. Про этот лишний такт у двойной индексной даже и не встречал наверное раньше информации. Премного благодарен. Хотелось бы ещё ссылку на первоисточник. Но вот дальше опять пошли светлый мысли. И где же вы на старых первых писюках видели частоты 12 или 16 МГц вместо 6 и 8? Частота кварца и процессора - это вещи разные и иногда в разы разные. Далее следует маленький расчет по пи-затвору (счет циклов есть в исходниках по процессорам 8088, 80186, 80286, 80386). Главный цикл программы для 80286 занисает 98 тактов. Число циклов для расчета 3000 цифр числа π находим из формулы 7*(4+3000)*3000/16. Полученное число умножаем на 98 и делим на 6 миллионов (6 МГц), получаем 64.4 секунды. Смотрим на данные из таблицы по XT/286 (там память без задержек). Там на 100 цифрах скорость 0.11 секунды, что означает, что сам вывод 3000 цифр в этой системе проходит примерно за 3 секунды. Итого получаем примерно 67.4 секунды. Данные с аппаратуры 71 секунда. Имеем разницу в 5%, которую можно объяснить задержками очереди команд и системной активностью. В вашем великолепном приведенном тексте говорится именно о такой 5-10% разнице. Подумаем чуть больше. Очередь команд у 80286 работает со скоростью не меньшей байт за два такта. Когда-то считал циклы для 68000 - там тоже все как на бумаге. А вам уважаемый, опять двойка. Стране нужен уран. А чтобы было веселее употреблять, вам на бонус песенка. :)
https://www.youtube.com/watch?v=jvyqO-1eT_4
Тогда не несите чушь и слушайте, что говорят те, кто работает с RSX с 84-ого года.
Слушают вас, уважаемый. Только не могли бы дать ссылки на свои программы? Вот у меня под пдп-11 архитектуру есть 3 больших проекта (кросс-компилятор бейсика, лаборатория клеточных автоматов, текстовый редактор) и один маленький (π-затвор).
Запросы к ядру
Оно и понятно.
Вообще то первый уровень - это каталог [0,0]. Рабочие каталоги - это уже второй уровень. Файловая система ODS-1. Третий уровень делали в P/OS. Поддержка третьего и дальше уровней штатно - ODS-2 и выше. Не могу сказать точно, почему не сделали, но судя по тому что я виде в исходниках VMS - это слишком ресурсно-затратно для тех времён. Хотя у меня есть мысль - добавить это дело на современных процессорах PDP-11
Если корень считать за уровень, то все файловые системы поддерживают каталоги. RSX-11 нет поддержки нормальной подкаталогов, в отличие от VMS. Добавить можно, но фирменного софта для этого нет. BQT сам такое написал - можете у него спросить - должен поделиться - зачем опять колесо изобретать?
Продвинутый пользователь перенес на неё RSX примерно лет за 10 до того, как на этом форуме поднялся вопрос (и долго муссировался), что RSX на ВМ3 не заработает, потому что в нём ошибки. Хорошо, что я примерно так в 91-92 годах об этом не подозревал и просто перенёс.
С этим Вам - респект.
Вы не спрашиваете. Вы утверждаете вещи, в которых не разбираетесь, по вашему же признаниюУважаемый оппонент, давайте факты. Признаю, что считал, что с большими кодами поддержка в RSX-11 существенно похуже и разговор с вами помог мне с этим разобраться. Нашел даже некоторые большие файлы на серверах BQT: компилятор бейсика - DU:[3,54]BP2IC2.TSK (992 блоков), си-компилятор DU:[3,54]PDP11C.TSK (985 блоков)... Однако, базовый вопрос был о том, что получить более 64 КБ в PDP-11 системах - это намного сложнее и тормознее, чем в ДОСе. И всё, что вы сообщаете, это подтверждает.
А ничего, что первая RSX вышла в 74 году? Или тогда тоже ставили "много" памяти?И первый ДОС вышел в 1981, когда по 64 КБ ставили. Думаю в это время на хорошие пдп-11 системы ставили уже все 4 метра, но для пользователя всё за пределами 64 кб получалось что-то типа памяти EMS для первых IBM PC, что-то типа продвинутого банкования.
Ещё одна полная хрень. Для RSX и XM монитора RT - отлично документировано и достаточно легко используется. Причём можно насчитать аж три подхода.
- прямая работа с соответствующими запросами к ядру системы
- непрямая работа - оверлеи, резидентные в памяти - в RSX. Вроде что то подобные было и в XM мониторе, но учитывая его убогую многозадачность, я RT практически не использую, поэтому сходу не могу не подтвердить, не опровергнутью
- массивы Virtual (теоретически - только под данные, но мы в своё время научились хитрить, но не получив от этого никакой пользы - для кода вернулись к пункту 2
Через прямые запросы к ядру много не наработаешь - хлопотно очень. Оверлеи - там надо со сценариями компоновщика колдовать (хотя некоторые компиляторы могут с этим помочь) и сама система очень тормознутая с множеством ограничений. Помню с чем-то таким на СР/М сталкивался. А для примитивной СР/М были даже хорошие электронные таблицы, которых на пдп-11 почему-то не хватило.
Могу ещё вам, эксперту (хотя скорее только опытному пользователю), кое-что подсказать. Можно ещё создавать отдельный сегмент для данных и получать адресуемых 128 КБ на процесс, но возможно ВМ3 этого не поддерживает, а KB11 и J11 поддерживают. Кроме того, есть ещё путанная возможность компоновать разделяемые библиотеки с исполняемой программой - плохо представляю, что это такое - разбирайтесь сами. Ещё есть что-то типа маппинга памяти - это как-то связано с виртуальными массивами - работать это должно очень небыстро. Осмелюсь предположить, что Х86 с перезагрузкой сегментного регистра для работы с большими массивами тут окажется на порядок или даже больше быстрее.
Хотя да, поскольку создатели Unix поделок шли каким-то своим тёмным путём - возможно, в Unix это так и осталось тёмным шаманством.
И Юникс не уважаете?
Те, кто в курсе, не спорят, что по состоянию на начало 80-х PDP-11 была лучшей 16-разрядной машинкой, и "феномен IBM PC" имел место быть только потому, что руководство и IBM, и DEC относились к самой идее персонального компьютера с глубочайшим презрением. Мол, модные игрушки, мода пройдет, а наши изделия останутся...
Уже были недешёвые системы на 68000 и в Штатах было много всего другого, но возможно по совокупности полезных свойств пдп-11 и был лучшей такой системой до года 83-84. По поводу презрения - сомневаюсь. Скорее чувствовали угрозу своему основному бизнесу (персоналки с конца 70-х пошли быстро растущей массой). IBM до PC сделала довольно популярный DataCenter, потом уже после PC какой-то комп на 68000, возможно ещё что-то. Повторю для вас, главная тема - это открытая архитектура IBM PC, так никогда раньше не делали. Чтобы не повторяться дам ссылку, там всё довольно конкретно - https://www.quora.com/Why-did-IBM-PCs-use-the-Intel-8086-and-not-the-Motorola-68000/answer/Travis-Casey-4
А тема началась с моего заявления, что 68000 не состоялся потому, что не он был выбран Межделмашем в ЦП для писюка. Все тут же полезли в детали, с пеной у рта доказывая, что интелёвые процессоры лучше - быстрее, удобнее для программирования и т.п. Забывая о том, что 68000 надо сравнивать не с 80386, и даже не с 80286, а с 8088 (не 86!). Именно между ними стоял выбор у Межделмаша.
Отстали мотороловцы, не было никакого выбора. Получилось у них позже, чем надо, и дороже, чем надо. Тупили они всегда много и с своими 8-битками и с 68к, много копировали, рекламировали, а про дело забывали. По мне 68000 был их реально лучший процессор, если сравнивать его относительно других, имевшихся тогда. В 1982 он начал теснить 8086/8088, но пришли 80286 и 80186...
И вперёд и назадНу если бы такое не сработало, но мы бы с вами ничего не знали про макро-11 и всю архитектуру пдп-11. Речь была о более сложном случае. Нужен макрос, который бы раскрывался в BR, когда переход короткий и в JMP, когда длинный. Его несложно написать, но он работает только для переходов назад, для переходов вперед он неправильно считает смещение.
- - - Добавлено - - -
странная какая конверсия в перевёрнутую строку, но ладно уж
только по-честному вместо mov для загрузки адреса буфера надо бы использовать lds
да и параметры в регистры dx:ax тоже как-то попадают сперва из памяти
но самое смешное, что код arm2, оптимизированный на скорость (~18 тактов на итерацию!) занимает не так чтобы очень много - 56 байт
а если вызывать деление процедурой (каковая всё равно еще где-нибудь в большой программе будет нужна) - только 20 байт :v2_dizzy_roll:
Что-то тупите, уважаемый. Передавать параметры в регистрах - штука обычная. А про арм-код не понял, где он? У арм2 нет аппратного деления, поэтому подобный код для арма должен быть весьма большим, сомневаюсь, что 56 байт хватит.
не-не-не, ничего такого там НЕ написано! :v2_dizzy_stop: первая часть:
...говорит о неких абстрактных "рисках", а вторая:
...говорит о том, что конкретно арм способен ОПРОВЕРГНУТЬ (дословно: "перевернуть") это предположение!
Похоже нужен урок английского. :) сode density is less so an application in RISC is likely to consume more memory than the equivalent in CISC - переводится как "плотность кодов [у RISC] - МЕНЬШЕ, так что приложение для RISC cкорее всего потребит больше памяти, чем эквивалентное для CISC". however the ARM has a few tricks up its sleeve to reverse this assumption - "однако, АРМ имеет несколько трюков в рукаве, которые могут опровергнуть это предположение"
это ссылка на исследование качества компиляторов 2010-х годов, причём после долгих лет застоя на поле армаЯ встречал и другие с примерно теми же результатами. 2010-е - это не 90-е. Если у вас есть обратные данные, дайте ссылку, сам таких не встречал.
сомневаюсь, что все поголовно не сомневались, почитав, как реагировали амижники :v2_laugh:Амиговцев понять можно - код 68000 довольно плотный, но армовцы никогда тут не спорили - зачем бы тогда нужно было Пальцы изобретать? Вот ссылка на мой материал по Арму - https://litwr.livejournal.com/2509.html -в комментах по плотности никто не отметился.
это то, что сделали ради мобильного рынка, где преобладали 16-битные шины, и на самом деле вовсе не для плотности, а для скорости
Почти везде, а может и везде про Пальцы пишут только как о способе повысить плотность кода. Хотя более плотные коды из-за лучшей утилизации кэша могут иметь и преимущества по скорости.
к тому времени амиги прекрасно закрывались самостоятельно в результате "эффективного менеджмента"
Менеджмент менеджментом, но отсутствие доступного по цене компа на 68к, способного запустить Дум - это тоже фактор.
нетушки, только половину этой роли они играют
Мне кажется, вы путаете понятие индексного и базового регистра. Сегменты х86 - никак не индексы, а только базы. В 68к адресные регистры базы могут быть использованы, пусть и с накладками, как индексы. Но писал про необходимую для всех операций с памятью базу. В 68к её надо задавать явно, в х86 она обычно присутствует неявно (можно задать префиксом для редкого случая). Конечно, с адресными регистрами можно работать более гибко, чем с сегментными. Но для простого задания базы - сегментные регистры х86 придуманы отлично.
вообще для знакомых с x86 архитектурой возня привычна, потому что программирование x86 - это и есть постоянная возня со ВСЕМИ регистрами :v2_lol:
А как же без возни с регистрами?! Это общий момент программирования на ассемблере.
так, стопэ, а байты откуда брать? как без адресных регистров читать из памяти?Это верно, отбросим один-два адресных 16-битных регистра для этих нужд и всё-равно у х86 получим 8 байтовых регистров и один-два парубайтовых. А пары байт можно брать и из стека, без адресных регистров (только SP).
как будто "пары байт" x86 для работы с байтами использовать очень просто - в основном обмен и временное хранение
но обмены есть и в 68000 - половинок регистров данных и целых регистров, включая адресные
что примерно так же можно применять для работы с байтами - и сколько тогда байтовой регистровой памяти?
почему это нельзя? из регистров данных можно грузить; и в арифметике и логике применять как байты-источникиПары байт в х86 отлично работают, а вот 68000 не работают вообще. Там поменять местами байты в слове - это большой тормоз - быстрее из памяти оба байта достать. И с адресными регистрами 68к байты никак не пойдут - байты туда грузить нельзя, только слова, а слова только с четного адреса (для байт - не пойдёт). И даже если вы поместите два байта в адресный регистр, вам чтобы достать их для обработки потребуется больше тактов, чем загрузить их оба из памяти в регистры данных. Итого по 68к имеем 8 байтовых регистров и всё, а х86 имеет чуть, но больше.
ага, нормальный такой мультитаскинг, при котором over 95% наличного софта не работает, всё отлично :v2_clapp:Вы опять про ДОС, который был ОДНОЗАДАЧНЫМ. Разработчики 80286 просто не могли знать про ДОС. Могу только удивляться оперативности Интел, который сделал поддержку многозадачности ДОС уже к 1985.
- наблюдаемая в объективной реальности over 95% амижных юзеровУ меня была Амига-500 с 1988 и экранчик Guru Meditation возникал очень даже нередко.
выключалку нужно написать один разО том и речь, маленький код сразу написал и готово. Не нужно текст набирать и потом такой хлам хранить, ассемблер запускать, ...
Только не могли бы дать ссылки на свои программы?
И чем вам драйвера помогут?
Вот у меня под пдп-11 архитектуру есть 3 больших проекта
Раз за вас
Если корень считать за уровень, то все файловые системы поддерживают каталоги.
Не каталоги, а подкаталоги. И подкаталоги - не все. RSX поддерживает (один уровень подкаталогов), MS-DOS 1.0 и 2.0 - нет
Однако, базовый вопрос был о том, что получить более 64 КБ в PDP-11 системах - это намного сложнее и тормознее, чем в ДОСе.
Если проводить аналогию с MS-DOS (которая не берёт на себя управление памятью), то это будет RT-11 SJ монитор - на системе с ДП загрузка аналога сегментного регистра - ровно одна команда. И этих сегментных регистров - восемь штук. Да, безусловно, это сложнее и тормознее.
Под ОС, которые берут на себя управление ДП, что бы программы друг друга не порушили не передрались за память - как и под другими ОС, типа Windows или Unix - будет не одна команда и ремаппинг будет дольше. Плата за центральную власть.
И первый ДОС вышел в 1981, когда по 64 КБ ставили. Думаю в это время на хорошие пдп-11 системы ставили уже все 4 метра
А вы не думайте, а поищите факты.
Через прямые запросы к ядру много не наработаешь - хлопотно очень.
Вы пробовали? Я пробовал.
Оверлеи - там надо со сценариями компоновщика колдовать (хотя некоторые компиляторы могут с этим помочь) и сама система очень тормознутая с множеством ограничений.
Вы пробовали? Я пробовал. Особенно люблю оверлеи, резидентные в памяти. Почитайте про них - глядишь, кругозор и расшириться
были даже хорошие электронные таблицы, которых на пдп-11 почему-то не хватило.
Это вы не в курсе про DECUS и софт оттуда
Могу ещё вам, эксперту (хотя скорее только опытному пользователю), кое-что подсказать. Можно ещё создавать отдельный сегмент для данных и получать адресуемых 128 КБ на процесс, но возможно ВМ3 этого не поддерживает, а KB11 и J11 поддерживают.
Ну прям открытие. Ничего, что я знаю про это с тыща-девятьсот лохматого года, а вон рядом стоит плата DE10, на которой крутился PDP-2011 с поддержкой всего этого? А теперь открытие - под RSX-11M-PLUS на J-11 я легко сделаю 128 кб КОДА плюс 64 кб данных
Кроме того, есть ещё путанная возможность компоновать разделяемые библиотеки с исполняемой программой - плохо представляю, что это такое - разбирайтесь сами.
Я эту возможность знаю и легко умею использовать с 1987 года плюс возможность одну разделяемую библиотеку компоновать с другой, плюс возможность любую из них размещать в любой странице ДП (спасибо PIC), плюс знаю как сделать возможным библиотеке обращаться к другой, без знания, с какого адреса она загружена. Просто надо знать RSX и уметь в ней работать.
Ещё есть что-то типа маппинга памяти - это как-то связано с виртуальными массивами - работать это должно очень небыстро.
И опять нулевые знания. Потому что для начала - с точностью до наоборот - виртуальные массивы связаны с возможностью менять маппинг страниц. И опять будет открытие, что компилятор с FORTAN-а поддерживает эти самые виртуальные массивы полностью прозрачно для программера
Осмелюсь предположить, что Х86 с перезагрузкой сегментного регистра для работы с большими массивами тут окажется на порядок или даже больше быстрее.
Осмеливаться будите, когда цифры приведёте - 8086 (1978 год) против PDP-11/70 (1974 год)
И Юникс не уважаете?
Ни в грош.
Ну если бы такое не сработало, но мы бы с вами ничего не знали про макро-11 и всю архитектуру пдп-11
Это на каком языке написано?
Нужен макрос, который бы раскрывался в BR, когда переход короткий и в JMP, когда длинный. Его несложно написать, но он работает только для переходов назад, для переходов вперед он неправильно считает смещение.
Учитывая, что компилятор MACRO-11 двухпроходной, на первом проходе он уже начинает расставлять команды по адресам и ему НУЖНО знать, сколько слов займёт команда, а на втором проходе он генерит код, учитывая, что BR (и её аналоги) занимает слово, а JMP слово или (обычно) два... Я могу сделать так, что бы генерировалось BR или JMP даже вперёд, но смысла из за особенностей MACRO-11 нет - BR займет два слова. Если же разбивать программу на небольшие подпрограммы - то BR хватит всегда
только по-честному вместо mov для загрузки адреса буфера надо бы использовать lds
LDS для работы с памятью, размером с десяток байт?!
И чем вам драйвера помогут?
Помогут, драйверы - это тоже программы.
Не каталоги, а подкаталоги. И подкаталоги - не все. RSX поддерживает (один уровень подкаталогов), MS-DOS 1.0 и 2.0 - нет
Было много пива? :) Каждый каталог, кроме корневого - подкаталог. :) А ДОС 2 очень даже каталоги поддерживает и на большую глубину. Вот специально для вас сделал снимок экрана - восхищайтесь - это Дос от 1982. 71539
Если проводить аналогию с MS-DOS (которая не берёт на себя управление памятью), то это будет RT-11 SJ монитор - на системе с ДП загрузка аналога сегментного регистра - ровно одна команда. И этих сегментных регистров - восемь штук. Да, безусловно, это сложнее и тормознее.
Мы говорим о довольно редких вещах. Читал когда-то, что пытались использовать эти регистры базы с системой RT11 и были проблемы.
А вы не думайте, а поищите факты.А что тут искать? Неужели заказчик не мог попросить 4 метра за свои деньги?!
Вы пробовали? Я пробовал.Очень интересно. И сколько займет код для обращения байту в массиве из 70000 байт?
Вы пробовали? Я пробовал. Особенно люблю оверлеи, резидентные в памяти. Почитайте про них - глядишь, кругозор и расширитьсяА что там такого особенного? Что-то типа использования EMS - банкуем странички.
Это вы не в курсе про DECUS и софт оттудаНе нашел там электронных таблиц. :( Помогите.
Ну прям открытие. Ничего, что я знаю про это с тыща-девятьсот лохматого года, а вон рядом стоит плата DE10, на которой крутился PDP-2011 с поддержкой всего этого? А теперь открытие - под RSX-11M-PLUS на J-11 я легко сделаю 128 кб КОДА плюс 64 кб данныхИзвините, но без вашей помощи не смогу понять, как можно 128 кб кода в 64 кб адресном пространстве.
Я эту возможность знаю и легко умею использовать с 1987 года плюс возможность одну разделяемую библиотеку компоновать с другой, плюс возможность любую из них размещать в любой странице ДП (спасибо PIC), плюс знаю как сделать возможным библиотеке обращаться к другой, без знания, с какого адреса она загружена. Просто надо знать RSX и уметь в ней работать.Отлично, но об этом и предыдущем случае вы не упомянули.
Осмеливаться будите, когда цифры приведёте - 8086 (1978 год) против PDP-11/70 (1974 год)Это про то, что 8086 гораздо более новая и продвинутая технология? Странная для Вас позиция, PDP-11 существено подороже и помощнее была. Только с 80286 (1982) началось технологическое отставание PDP-11. Цифры для PDP-11 не знаю, прошу тут Вашей помощи, а для х86 это лишняя загрузка сегментного регистра и обращение к памяти через префикс, т.е. чуть больше одной команды.
Ни в грош.Так не долго и в маргиналы попасть.
Учитывая, что компилятор MACRO-11 двухпроходной, на первом проходе он уже начинает расставлять команды по адресам и ему НУЖНО знать, сколько слов займёт команда, а на втором проходе он генерит код, учитывая, что BR (и её аналоги) занимает слово, а JMP слово или (обычно) два... Я могу сделать так, что бы генерировалось BR или JMP даже вперёд, но смысла из за особенностей MACRO-11 нет - BR займет два слова. Если же разбивать программу на небольшие подпрограммы - то BR хватит всегда
BR займет два слова вместо одного?! И зачем такое нужно?! А макрос такой очень даже полезный для систем, где исторически и архитектурно, с памятью не густо. Но макро-11 не умеет. :(
Помогут, драйверы - это тоже программы.
Аха. Конечно.
Мы говорим о довольно редких вещах. Читал когда-то, что пытались использовать эти регистры базы с системой RT11 и были проблемы.
Это вы расскажите виртуальным массивам фортрана под SJ на системах с ДП. Или моему драйверу CF под RSX, который только что начал играться с регистрами ДП
А что там такого особенного?
Вот именно что ничего особенного и сложного.
Не нашел там электронных таблиц. Помогите.
Ищите да обрящете. А у меня своих дел хватает. Нет.
Извините, но без вашей помощи не смогу понять, как можно 128 кб кода в 64 кб адресном пространстве.
Документация на RSX-11M-Plus и на, скажем, J-11
Отлично, но об этом и предыдущем случае вы не упомянули.
Так надо было вопросы задавать уметь, а не так, что бы о телепатии начинаешь жалеть.
Это про то, что 8086 гораздо более новая и продвинутая технология?
Это про то, что более старая машину уделает более новую
Так не долго и в маргиналы попасть.
Мне как то фиолетово, что не и мало знакомые люди обо мне думают
А макрос такой очень даже полезный
Вот в качестве домашнего задания и напишите его
Адиос
Аха. Конечно.Так я думал - вам и показать нечего. :(
Это вы расскажите виртуальным массивам фортрана под SJ на системах с ДП. Или моему драйверу CF под RSX, который только что начал играться с регистрами ДПВаш драйвер? У мощного DEC сил не нашлось сделать, а самоделкин демку сделал? Вот о том и речь, что эти возможности - это только современные надуманные изыскания, которые в штатных системах были на обочине развития.
Ищите да обрящете. А у меня своих дел хватает. Нет.Так нет ничего. Википедия про Мультиплан: есть для CP/M, Apple II, Macintosh, MS-DOS, Xenix, Commodore 64, CTOS, TI-99/4A, TRS-80, Thomson computers - для PDP-11 нет; Supercalc: есть для CP/M, MS-DOS, VMS - для PDP-11 нет; Visicalc: есть для Apple II, Apple SOS, CP/M, Atari 8-bit family, Commodore PET, TRSDOS, Sony SMC-70, DOS, HP series 80 - нету для PDP-11. Не было для пидипей таблиц. :( Может самоделкины сделают? У меня знакомый для 8-битки сделал класные таблицы (https://www.youtube.com/watch?v=Sr01QX_23dc). Неужели для 16-битки никто не возьмётся? :( Все только "драйвера" пишут для магазина? :)
Документация на RSX-11M-Plus и на, скажем, J-11Вас просили помочь. Нужно лишь несколько слов. Могу предположить, что можно как-то все адреса кодов указывать деленными на два - неужели так можно?
Так надо было вопросы задавать уметь, а не так, что бы о телепатии начинаешь жалеть.Так сами написали якоды исчерпывающий список. Вот и подумал, не знаете, решил помогать. Где же мне добыть телепатию или телепата?!
Вот в качестве домашнего задания и напишите егоПомню всем БК-миром пробовали, не осилили - слаб макро-11 для настоящих макро. :(
Так я думал - вам и показать нечего
Беда-беда-печаль.
аш драйвер? У мощного DEC сил не нашлось сделать, а самоделкин демку сделал?
Штатный механизм, предусмотренный DEC
Википедия
Прям светоч знаний
Вас просили помочь. Нужно лишь несколько слов.
Несколько слов - читаем доки
Помню всем БК-миром пробовали, не осилили - слаб макро-11 для настоящих макро
Или слаб мир БК
Lethargeek
17.02.2020, 02:10
LDS для работы с памятью, размером с десяток байт?!
а где гарантии, что в ds нужное значение перед вызовом? то, что там всегда одно значение - не предлагать! тогда это не полноценный аналог того кода 68k
Передавать параметры в регистрах - штука обычная.
как и чтение из памяти их в регистры (разве что результат долгих вычислений требуется сразу в ascii)
А про арм-код не понял, где он? У арм2 нет аппратного деления, поэтому подобный код для арма должен быть весьма большим, сомневаюсь, что 56 байт хватит.
так это же деление на константу - вот что предлагают в древней книжке 1994 года:
SUB a2, a1, #10 ; keep (x-10) for later
SUB a1, a1, a1, lsr #2
ADD a1, a1, a1, lsr #4
ADD a1, a1, a1, lsr #8
ADD a1, a1, a1, lsr #16
MOV a1, a1, lsr #3
ADD a3, a1, a1, asl #2
SUBS a2, a2, a3, asl #1 ; calc (x-10) - (x/10)*10
ADDPL a1, a1, #1 ; fix-up quotient
ADDMI a2, a2, #10 ; fix-up remainder
итого 10 команд, 40 байт, 10 тактов - ха-ха, против ~300 тактов пары аппаратных интелевских делений :v2_laugh:
(притом даже универсальное деление на арм2 емнип в среднем вдвое быстрее аппаратного 8086)
если к этому куску добавить обвязку:
LDR a4, _BUFFER
_LOOP: udiv10 из примера
ORR a2, a2, '0'
STRB a2, [a4, #1]!
CMP a1, #0
BNZ _LOOP
MOV pc, lr
получилось 64 байта с инлайном (чуть наврал, в уме забыл учесть две команды)
...но всё равно :v2_dizzy_roll:
Похоже нужен урок английского.
точно нужен, вот только совсем не мне :v2_dry:
сode density is less so an application in RISC is likely to consume more memory than the equivalent in CISC - переводится как "плотность кодов [у RISC] - МЕНЬШЕ, так что приложение для RISC cкорее всего потребит больше памяти, чем эквивалентное для CISC"
и? что здесь противоречит моим словам о неконкретности этой части утверждения? при том, что здесь даже не "highly likely" )))
however the ARM has a few tricks up its sleeve to reverse this assumption - "однако, АРМ имеет несколько трюков в рукаве, которые могут опровергнуть это предположение"
а вот здесь как раз однозначно "ЧТОБЫ опровергнуть" без всяких "могут"
Я встречал и другие с примерно теми же результатами. 2010-е - это не 90-е.
вот именно, SIMD уже играли слишком большую роль и на десктопных интелах были тупо шире мобильных армовских
положение стало выправляться совсем недавно
Если у вас есть обратные данные, дайте ссылку, сам таких не встречал.
сразу не найду, где-нибудь лежат на старом компе, или надо снова искать по форумам :(
Амиговцев понять можно - код 68000 довольно плотный, но армовцы никогда тут не спорили - зачем бы тогда нужно было Пальцы изобретать?
Повнимательней, я уже ответил выше на сей вопрос. Затем, чтобы скорость не проседала вдвое на узких шинах, когда арм стали предлагать для мобилок. Несколько улучшенная компактность (которую отдел маркетинга арма не замедлил начать пиарить) здесь не цель и не причина, а только следствие.
Почти везде, а может и везде про Пальцы пишут только как о способе повысить плотность кода.
на заборе тоже пишут много чего
Хотя более плотные коды из-за лучшей утилизации кэша могут иметь и преимущества по скорости.
thumb впервые появился в ARM7TDMI, применявшемся обычно без всяких кэшей, зато именно в мобильных устройства, где ради экономии шину резали
Менеджмент менеджментом, но отсутствие доступного по цене компа на 68к, способного запустить Дум - это тоже фактор.
это тоже следствие менеджмента
Мне кажется, вы путаете понятие индексного и базового регистра.
Именно что кажется (как всегда) - собственные сообщения забываем?
У х86 роль адресных играют сегментные регистры,
итак, кто сам же и сказал "адресных"? АДРЕСНЫХ - не индексных и не базовых! но ПОЛНЫЙ адрес x86 содержится в ДВУХ регистрах
Сегменты х86 - никак не индексы, а только базы.
и никак не базы, потому что BASE pointer - это bp :v2_dizzy_biggrin2: у нормальной базы не должно быть ограничений на положение
В 68к адресные регистры базы могут быть использованы, пусть и с накладками, как индексы.
нет, как раз там они могут быть действительно использованы как АДРЕСНЫЕ, то есть содержащие ПОЛНОЦЕННЫЙ адрес в ОДНОМ регистре
А как же без возни с регистрами?!
например, как в армовском коде выше - и вероятнее, что нужное число регистров будет свободно, и голова из-за их специализации не болит
Это общий момент программирования на ассемблере.
...для процессоров с вопиющим дефицитом даже неуниверсальных регистров (то есть восьмибитных и старых интелов))
Это верно, отбросим один-два адресных 16-битных регистра для этих нужд и всё-равно у х86 получим 8 байтовых регистров и один-два парубайтовых. А пары байт можно брать и из стека, без адресных регистров (только SP).
но уже только последовательно (вот она, возня, уже началась)))
Пары байт в х86 отлично работают, а вот 68000 не работают вообще. Там поменять местами байты в слове - это большой тормоз - быстрее из памяти оба байта достать.
А вот не нужно байты в слове менять - можно поменять слова и работать с младшим байтом каждого слова, забив на старшие. Встречный вопрос - а как в x86 поменять без тормозов местами байты в суперудобных "парубайтовых" di/si/bp? Ааась?
И даже если вы поместите два байта в адресный регистр, вам чтобы достать их для обработки потребуется больше тактов, чем загрузить их оба из памяти в регистры данных. Итого по 68к имеем 8 байтовых регистров и всё, а х86 имеет чуть, но больше.
неееет, итого имеем в мотороле:
= 8 байтовых регистров (младшие байты регистров данных)
= 8 байт еще для обмена с ними (третьи байты регистров данных)
+ до 7 байт-источников в адресных регистрах
А что же в 8086? 8 байтовых регистров и до 3 "парубайтовых", с которыми непонятно как работать, кроме xchg. Но так можно и в мотороле.
То есть полноценных байтовых в 68k столько же, зато вспомогательных - вдвое больше, и функционал у них шире.
Вы опять про ДОС, который был ОДНОЗАДАЧНЫМ.
и почему же он с таким расчудесным супер-пупер-ММЮ на сегментах был однозадачным?
Могу только удивляться оперативности Интел, который сделал поддержку многозадачности ДОС уже к 1985.
об чём речь? на пц многозадачность стала робко пробиваться с 386 (а скорости хватать стало только с 486)
У меня была Амига-500 с 1988 и экранчик Guru Meditation возникал очень даже нередко.
так это аналог BSOD, то есть сбоя в компонентах самой системы, который и под виндой с настоящим MMU (а не "мемею") регулярно
О том и речь, маленький код сразу написал и готово. Не нужно текст набирать и потом такой хлам хранить, ассемблер запускать, ...
нет, речь о том, что лучше уж раз в полгода запустить лишнюю софтварь ради ерунды, чем всю жизнь таскать харварные костыли
Несколько слов - читаем доки
Или слаб мир БК
Оказывается всё просто, юзер использует системные вызовы как подпрограммы - это не настоящие 128 кб кода, а только что-то похожее на них. И, уважаемый эксперт, поделились бы своим знанием, не хоронили бы его, просветили публику. Мне вот представляется, что многие ограничения макро-11 - это следствие его 2-проходности, которой часто не хватает, например, даже .word . он не осилит. FASM запросто может делать по 4 и более проходов.
а где гарантии, что в ds нужное значение перед вызовом? то, что там всегда одно значение - не предлагать! тогда это не полноценный аналог того кода 68k
Чувствуется, что не делали вы кодов для 68000. Там если смещение более 64 кб, нужно менять базовый адресный регистр. И добавим к этому немного здравого смысла: все маленькие данные естественно хранить в одном сегменте.
как и чтение из памяти их в регистры (разве что результат долгих вычислений требуется сразу в ascii)И в чем тут у вас проблема?
так это же деление на константу - вот что предлагают в древней книжке 1994 года:
итого 10 команд, 40 байт, 10 тактов - ха-ха, против ~300 тактов пары аппаратных интелевских делений :v2_laugh:
(притом даже универсальное деление на арм2 емнип в среднем вдвое быстрее аппаратного 8086)
Благодарю за интесный алгоритм. Явно АРМ уделывает 8086 по скорости раз в 30, но по размеру кода проигрывает почти в два раза. Если сравним с более близким по времени 80286, то по скорости для 32-битных данных 80286 проиграет раза в полтора при том же выигрыше по размеру кода, а для 16-битных он уже существенно обгонит АРМ. Ровестник АРМ, 80386, обгонит его и по слегка скорости, и сильно (раз в 30) по размеру кода. Для универсального деления АРМ сильно отстает от 80286 и 80386.
если к этому куску добавить обвязку:
получилось 64 байта с инлайном (чуть наврал, в уме забыл учесть две команды)
LDR - это макрос и он может быть и 8 и даже более байт. Хотя если заменить ADDPL на ADDPLS, то можно убрать CMP, с учетом LDR получим опять примерно те же 64 байта, т.е. несмотря на все очень непростые алгоритмические трюки в более два раза больше, чем 8088, и почти в два раза больше, чем 68000.
а вот здесь как раз однозначно "ЧТОБЫ опровергнуть" без всяких "могут"Смысл от этого не меняется, "могут" означает способны сделать, делают иногда. Но общий смысл такой как вам изначально написали, а именно, обычно коды х86 плотнее, но у АРМа есть трюки... На всех примерах, где использовали очень сложные трюки (ваш алгоритм деления на 10 или код английского эксперта для рисования линии), преимущества для АРМ не получилось.
вот именно, SIMD уже играли слишком большую роль и на десктопных интелах были тупо шире мобильных армовских положение стало выправляться совсем недавно
сразу не найду, где-нибудь лежат на старом компе, или надо снова искать по форумам :(Для АРМ компиляторы стали делать хорошо к концу 90-х, поэтому сомневаюсь, что найдете. Мощные у АРМ команды, но и большие.
Повнимательней, я уже ответил выше на сей вопрос. Затем, чтобы скорость не проседала вдвое на узких шинах, когда арм стали предлагать для мобилок. Несколько улучшенная компактность (которую отдел маркетинга арма не замедлил начать пиарить) здесь не цель и не причина, а только следствие.Может исторически это отчасти и верно, но сейчас на размере шине не особо сэкономишь, а Пальцы в ходу там, где ставят мало памяти..
на заборе тоже пишут много чегоВам предложили научные исследования, мог бы ещё подкинуть ссылок, но оставлю их нагуглить вам.
Именно что кажется (как всегда) - собственные сообщения забываем?Можно поконкретнее? Может надо объяснить, если чего не поняли? У вас 68к с АРМ реально путалось...
итак, кто сам же и сказал "адресных"? АДРЕСНЫХ - не индексных и не базовых! но ПОЛНЫЙ адрес x86 содержится в ДВУХ регистрах
В смысле PC? Вы бы ещё вспомнили трансляционные таблицы для линейного адреса в современных системах, там не два, там много! Но это всё за кулисами, а юзер просто работает с РС. Так и с древним 8086, там там CS подразумевается в абсолютном большинстве случаев. Явно его указывать нужно только для длинных переходов. Такая же ситуация и с данными, а на 68к нужно, повторю, ЯВНО указывать базовый регистр. Неужели не понимаете, что явное указание регистра, это и головная боль программеру и лишний тормоз в системе.
и никак не базы, потому что BASE pointer - это bp :v2_dizzy_biggrin2: у нормальной базы не должно быть ограничений на положениеА вы с х86 знакомы? BP - это для работы со стеком, довесок к SP. База нужна, чтобы использовать более коpоткие адреса относительно неё. Поэтому BP по сути - это индексный регистр стека. На каком-то вторичном уровне восприятия это база стековых данных. Понятия индекса и базы иногда смешиваются, поскольку база тоже может быть относительной, а относительная база - это индекс.
нет, как раз там они могут быть действительно использованы как АДРЕСНЫЕ, то есть содержащие ПОЛНОЦЕННЫЙ адрес в ОДНОМ регистреТут я описался, имелось в виду не адресные, а базовые. Хотя это лишь оттенки смыслов, по сути всё было верно. Чем адрес в сегментном регистре неполноценный? Не хватает 4 бит, так для базы выравнивание - это норм.
например, как в армовском коде выше - и вероятнее, что нужное число регистров будет свободно, и голова из-за их специализации не болит
...для процессоров с вопиющим дефицитом даже неуниверсальных регистров (то есть восьмибитных и старых интелов))
Специализация давала возможность иметь более плотные коды (код 8086 более плотный, чем у современных х86). Сколько вы кодов х86 написали? Я более 100000 строк и считаю, что проблема специализации надуманная. Конечно, иметь много регистров - это хорошо, но не однозначно хорошо. Если иметь быструю память (а сегодня поставить даже гигабайт статической нетормозящей память вполне бюджетно), то можно и с минимумом регисторов получить отличную скорость. Пример 6502 это подтвреждает, который в почти три раза уделывал z80 на той же частоте. У z80, напомню, было гораздо больше регистров, чем у 6502. Пока только англичане со своим Графкор пробивают зомби-пелену, наведленную Интел/Нвидия с архитектурой очень медленная память плюс много кэшей.
но уже только последовательно (вот она, возня, уже началась)))Не понял, где вы тут увидели проблему?
А вот не нужно байты в слове менять - можно поменять слова и работать с младшим байтом каждого слова, забив на старшие. Встречный вопрос - а как в x86 поменять без тормозов местами байты в суперудобных "парубайтовых" di/si/bp? Ааась?Загрузить, например, в AX и сделать XCHG - в 68000 так не получится, там нет XCHG.
неееет, итого имеем в мотороле:
= 8 байтовых регистров (младшие байты регистров данных)
= 8 байт еще для обмена с ними (третьи байты регистров данных)
+ до 7 байт-источников в адресных регистрах
А что же в 8086? 8 байтовых регистров и до 3 "парубайтовых", с которыми непонятно как работать, кроме xchg. Но так можно и в мотороле.Реально вы хоть какой-то код для 68000 делали? Как вы там сможете использовать "третьи байты регистров данных"? Никак или с такими тормозами, что быстрее их брать прямо из памяти. Про адресные регистры уже писал - они мало приспособленны для данных, хотя как временный кэш для байт для загрузки-выгрузки из/в регистров данных подойдут. Но 8086 парубайтки существенно гибче для таких случаев
То есть полноценных байтовых в 68k столько же, зато вспомогательных - вдвое больше, и функционал у них шире.Спорим только о качестве вспомогательных. Мой опыт, что на 8086 они лучше, хотя для некоторых редких случаев 68000 возможно может иметь преимущества.
и почему же он с таким расчудесным супер-пупер-ММЮ на сегментах был однозадачным?Шутим? Не было там нормального ММЮ, но если бы развитие пошло по ПДП-11 варианту, то такое полу-ММЮ могло бы неплохо сработать для бюджетных систем. А ДОС - это копия СР/М - с чего бы ему быть многозадачным?
об чём речь? на пц многозадачность стала робко пробиваться с 386 (а скорости хватать стало только с 486)Не понятно о чем это вы пишите. В 80386 сделали отличную поддержку многозадачности для ДОС. Софт не успевали делать и была проблема эмуляции видео и звука, которых на РС становилось всё больше и процессор с этим не справлялся.
так это аналог BSOD, то есть сбоя в компонентах самой системы, который и под виндой с настоящим MMU (а не "мемею") регулярноЧувствуется, что никогда вы не писали кодов для Амиги, а мне приходилось - и вот малейшая ошибка рушила систему - это далеко не Unix или RSX-11.
нет, речь о том, что лучше уж раз в полгода запустить лишнюю софтварь ради ерунды, чем всю жизнь таскать харварные костылиНе понял, вам дают маленькое удобство, свободу от компоновщика, а вам плохо. Типа, хочу тупить лишние операции? Может в современных супертяжелых системах такие удобства маловостребованы, но когда-то, когда всё только начиналось, это было неплохим подспорьем.
Оказывается всё просто, юзер использует системные вызовы как подпрограммы - это не настоящие 128 кб кода, а только что-то похожее на них.
Доки читайте внимательней. Инструкция (а не системный вызов) CSM
И, уважаемый эксперт, поделились бы своим знанием, не хоронили бы его, просветили публику.
Документации в инете - валом. Научились бы читать на английском и пользоваться гуглом.
например, даже .word . он не осилит.
Правда?
TEST MACRO V05.06R Sunday 23-Feb-20 Page 1
1 .TITLE TEST
2 .MCALL .EXIT
3
4 000000 START:
5 000000 .EXIT
6 000002 000002' W: .WORD .
7 000000' .END START
TEST MACRO V05.06R Sunday 23-Feb-20 Page 1-1
Symbol table
START 000000R W 000002R
. ABS. 000000 000 (RW,I,GBL,ABS,OVR)
000004 001 (RW,I,LCL,REL,CON)
Errors detected: 0
*** Assembler statistics
Work file reads: 0
Work file writes: 0
Size of work file: 60 Words ( 1 Pages)
Size of core pool: 13056 Words ( 51 Pages)
Operating system: RT-11
Elapsed time: Unknown
DK:TTT,DK:TTT=DK:TTT
Документации в инете - валом. Научились бы читать на английском и пользоваться гуглом.Так помогите нам, неумелым, никак не можем найти. На вас вся надежда.
Правда?
Всё про RSX-11 писали, а тут до RT-11 снизошли. He понятно... Ho по существу вы правы, проблема была в том, что адрес не был выровнен, на х86 такой проблемы не возникло бы. Ho это - мелочь, главный вопрос как макро-11 уговорить на макрос с правильным переходом.
Так помогите нам, неумелым, никак не можем найти. На вас вся надежда.
Юродствуем? Ну ну.
Всё про RSX-11 писали, а тут до RT-11 снизошли.
А причём здесь операционка? MACRO-11 один и тот же. И про вызовы к ядру ОС он вообще ни сном ни духом
Юродствуем? Ну ну.
А причём здесь операционка? MACRO-11 один и тот же. И про вызовы к ядру ОС он вообще ни сном ни духом
Если вы на просьбу о помощи только хамите, ваше право. И про ядро не писал - это вы выдумали. А вот макро-11 не смог у меня посчитать размер памяти, например, MEMSZ = 65536 - .
Можно вместо 65536 взять другое число, минус не работает.
И про ядро не писал - это вы выдумали.
Ещё раз. Про вызовы к ядру MACRO-11 ни сном ни духом. Поэтому возможности языка можно показывать, транслируясь под ЛЮБОЙ операционкой.
А вот макро-11 не смог у меня посчитать размер памяти, например, MEMSZ = 65536 - .
А каким образом число 65536 влезет в 16 бит - вы подумали?
А те кто думает, пишут так MEMSZ = 65535.-.+1
И всё нормально считается. Ну кроме случая, когда программа занимает всю память
Lethargeek
23.02.2020, 19:48
Чувствуется, что не делали вы кодов для 68000. Там если смещение более 64 кб, нужно менять базовый адресный регистр.
уже не помню, но при чём тут вообще смещение? когда нужен просто инкремент указателя
И добавим к этому немного здравого смысла: все маленькие данные естественно хранить в одном сегменте.
ага, и не забыть устанавливать ds перед вызовом одной или нескольких таких процедур (то есть код еще особо надо группировать)
в любом случае: начались какие-то оговорки - это значит, что один код не является полностью аналогом другого кода функционально
И в чем тут у вас проблема?
в том, что вероятней сперва расчёт, а потом уж вывод пачкой всех результатов
и тогда загрузка оных из памяти непосредственно относится к процедуре
Благодарю за интесный алгоритм. Явно АРМ уделывает 8086 по скорости раз в 30,
в 18 раз на одинаковой частоте (если брать всю итерацию, а не только деление)
но по размеру кода проигрывает почти в два раза.
это для развёрнутой процедуры, а для вызова - по размеру (и даже всё еще по скорости) арм будет лучше
Если сравним с более близким по времени 80286, то по скорости для 32-битных данных 80286 проиграет раза в полтора при том же выигрыше по размеру кода, а для 16-битных он уже существенно обгонит АРМ.
ага, щяз :v2_dizzy_stop: на 32-битных проиграет в 3.6+ раза (и на 16-битных не должен обогнать)
Ровестник АРМ, 80386, обгонит его и по слегка скорости,
вот конкретно в этой задаче не обгонит даже на удвоенной частоте (а первые 386 шли от 12мгц)
и сильно (раз в 30) по размеру кода.
шта? опять смешались мухи с котлетами... в данном случае размер кода будет близок к 8086 варианту
для универсального же деления, в армокоде будет просто "BL udiv", который всяко нужен неоднократно
Для универсального деления АРМ сильно отстает от 80286 и 80386.
да не так уж сильно, раза в полтора в среднем (и это для полностью программной реализации!)
зато очень быстрое умножение, которое нужно намного чаще, в том числе неявно (адрес в массиве)
LDR - это макрос и он может быть и 8 и даже более байт.
а может и не быть, конкретно здесь хватит результата PC+N
Хотя если заменить ADDPL на ADDPLS, то можно убрать CMP,
здесь нельзя, ADDPL не каждый раз выполняется
несмотря на все очень непростые алгоритмические трюки в более два раза больше, чем 8088, и почти в два раза больше, чем 68000.
а с вызовом универсальной (или частных случаев) процедуры - меньше!
Смысл от этого не меняется, "могут" означает способны сделать, делают иногда.
да мне пофиг, какой смысл у слова "могут" - ЕГО ТАМ НЕТ!
На всех примерах, где использовали очень сложные трюки (ваш алгоритм деления на 10 или код английского эксперта для рисования линии), преимущества для АРМ не получилось.
трюки есть и менее сложные (например, прочесть пачку аргументов одной командой там, где 386 вынужден уныло копаться в стеке) и результаты следует оценивать комплексно
Вам предложили научные исследования,
совершенно к делу не относящиеся
Можно поконкретнее? Может надо объяснить, если чего не поняли? У вас 68к с АРМ реально путалось...
:v2_dizzy_facepalm: поконкретнее - я там забытое напомнил сразу СЛЕДУЮЩЕЙ СТРОКОЙ
В смысле PC? Вы бы ещё вспомнили трансляционные таблицы для линейного адреса в современных системах, там не два, там много! Но это всё за кулисами, а юзер просто работает с РС. Так и с древним 8086, там там CS подразумевается в абсолютном большинстве случаев. Явно его указывать нужно только для длинных переходов. Такая же ситуация и с данными, а на 68к нужно, повторю, ЯВНО указывать базовый регистр. Неужели не понимаете, что явное указание регистра, это и головная боль программеру и лишний тормоз в системе.
:v2_wacko: какой PC? какой базовый регистр? для начала - просто ПОЛНОЦЕННЫЙ АДРЕС ЯЧЕЙКИ ПАМЯТИ
А вы с х86 знакомы?
лучше, чем с 68k или армом (на ассемблере последний раз писал Форт себе со встроенным отладчиком спектрума)
BP - это для работы со стеком, довесок к SP. База нужна, чтобы использовать более коpоткие адреса относительно неё.
база нужна, чтоб адресовать НАЧАЛО СТРУКТУРЫ (в широком смысле)
и уж точно без дурацких лишних ограничений на аж 16-байтовое выравнивание :v2_sick:
Понятия индекса и базы иногда смешиваются, поскольку база тоже может быть относительной, а относительная база - это индекс.
нет, база всегда - НАЧАЛО отсчёта (порции) данных
Тут я описался, имелось в виду не адресные, а базовые. Хотя это лишь оттенки смыслов,
не "оттенки смыслов", а принципиально разные вещи
Чем адрес в сегментном регистре неполноценный? Не хватает 4 бит, так для базы выравнивание - это норм.
для каких-нибудь системных стеков, может, и норм, а для настоящей базы работы с данными - это нонсенс :v2_sick:
Специализация давала возможность иметь более плотные коды (код 8086 более плотный, чем у современных х86). Сколько вы кодов х86 написали? Я более 100000 строк и считаю, что проблема специализации надуманная.
см. выше - дохренища я написал и специализация надоела
Конечно, иметь много регистров - это хорошо, но не однозначно хорошо. Если иметь быструю память (а сегодня поставить даже гигабайт статической нетормозящей память вполне бюджетно), то можно и с минимумом регисторов получить отличную скорость. Пример 6502 это подтвреждает, который в почти три раза уделывал z80 на той же частоте.
во-1 не в три раза, а от силы в два, иначе прямые спектрумовские порты так заметно на комоде не тормозили бы (в отличие портов на атари с его как раз ровно вдвое меньшей частотой камня); во-2, пример 6502 подтверждает как раз обратное, потому что он вообще не мог работать на таких частотах, чтобы догнать, будучи привязанным к памяти; в-3, если память не ограничивает скорость проца вообще, то она регистрами и является (потому что даже кэш на одном кристалле даёт задержки)
Не понял, где вы тут увидели проблему?
:v2_dizzy_tired2: в возне со стеком (но да, на x86 это не "проблема", там это жизнь)))
Загрузить, например, в AX и сделать XCHG - в 68000 так не получится, там нет XCHG.
точно, XCHG нету :v2_dizzy_biggrin2: есть EXG - обмен между регистрами; и между половинками регистра данных (SWAP называется) :v2_dizzy_botan:
Реально вы хоть какой-то код для 68000 делали?
спрашивает человек, не знающий команд обмена 68000 :v2_dizzy_facepalm:
Как вы там сможете использовать "третьи байты регистров данных"?
еще раз, для закрепления материала: SWAP
Никак или с такими тормозами, что быстрее их брать прямо из памяти.
не быстрее
Про адресные регистры уже писал - они мало приспособленны для данных, хотя как временный кэш для байт для загрузки-выгрузки из/в регистров данных подойдут.
а я писал, что и в арифметике подойдут
Но 8086 парубайтки существенно гибче для таких случаев
для КАКИХ? в вычислениях применять их можно только парой, только для логики
что ни гибче, ни тем более "существенно" гибче
Шутим? Не было там нормального ММЮ,
то есть "отличный ММЮ" раньше было в смысле "Хопёр-Инвест отличная компания (от других)"? :v2_laugh:
Чувствуется, что никогда вы не писали кодов для Амиги, а мне приходилось - и вот малейшая ошибка рушила систему
чувствуется закономерность результата :v2_dizzy_biggrin2:
Не понял, вам дают маленькое удобство, свободу от компоновщика, а вам плохо.
ага, бизнес дона Интелоне - сломать ногу и предложить костыль как "удобство" :v2_clap2:
Ещё раз. Про вызовы к ядру MACRO-11 ни сном ни духом. Поэтому возможности языка можно показывать, транслируясь под ЛЮБОЙ операционкой.
А каким образом число 65536 влезет в 16 бит - вы подумали?
А те кто думает, пишут так MEMSZ = 65535.-.+1
И всё нормально считается. Ну кроме случая, когда программа занимает всю память
Что за ерунда? Откуда опять ядро?! Вам про то, что вы тут RSX-11 якобы продвигаете, а сами втихомолку являетесь поклонником RT-11. Про числа написал ясно - любые.
А макрос вы теперь очевидно и сами не знаете как делать. Как и писал, несколько лет назал знающие люди на БК форуме (среди них возможно и вы были) искали и не нашли.
уже не помню, но при чём тут вообще смещение? когда нужен просто инкремент указателя
Возьмем типичную команду загрузки из памяти MOVE data(a3),d0. В этой команде a3 - база, а data - это 16-БИТНОЕ смещение, если вам нужны данные, которые не влазят в 64 КБ (например, data2), то базу надо менять. Это абсолютно аналогично ситуации с х86.
ага, и не забыть устанавливать ds перед вызовом одной или нескольких таких процедур (то есть код еще особо надо группировать)
в любом случае: начались какие-то оговорки - это значит, что один код не является полностью аналогом другого кода функционально
Ничего не понял. Повторю, что естественно все данные небольшого размера держать в DS. А во времена дефицита памяти, когда даже 512 КБ было очень много, это было более чем нормально. Что тут не так? Если вы про CS, то меняя его легко получаем 1 МБ для подпрограмм, которые используют один и тот же DS. И тут что для вас не так? Два типа подпрограмм тяжело использовать?
в том, что вероятней сперва расчёт, а потом уж вывод пачкой всех результатов
и тогда загрузка оных из памяти непосредственно относится к процедуре
Извините, но никак не пойму. Может скажете более конкретно, что именно вам не понраравилось в приведенных кодах?
в 18 раз на одинаковой частоте (если брать всю итерацию, а не только деление)У меня получилось для АРМа 16 тактов, а для 8086 более 300. Деление на 8086 выполняется за разное число тактов для разных аргументов, поэтому подсчитать точное число тактов очень непросто и неоднозначно.
это для развёрнутой процедуры, а для вызова - по размеру (и даже всё еще по скорости) арм будет лучшеЭто, как говорят, не спортивно.
ага, щяз :v2_dizzy_stop: на 32-битных проиграет в 3.6+ раза (и на 16-битных не должен обогнать)универсальное 32-битное деление на 80286 - это примерно 51 такт, специализированное деление на 10 у Арма - это 40 тактов. Получаем 51/40 = 1.275, т.е. выигрыш Арма на примерно четверть. Если в универсальном делении использовать делитель 10, то для 80286 получим уже примерно 64 такта. В этом случае получаем 64/40 = 1.6 и опять и близко не 3.6
вот конкретно в этой задаче не обгонит даже на удвоенной частоте (а первые 386 шли от 12мгц)универсальное 32-битное деление на 80386 - это 38 тактов - обгонит и на той же частоте.
шта? опять смешались мухи с котлетами... в данном случае размер кода будет близок к 8086 варианту
для универсального же деления, в армокоде будет просто "BL udiv", который всяко нужен неоднократноУниверсальное 32-битное деление на 80386 - это одна команда от 2 до 4 байт, на Арме, если делать побыстрее без циклов, то более 200 байт, а с циклами - не менее 60. И это про Арм-варианты, когда делимое 32 бита. На 80386 оно 64 бита. На 80286 и 8086 делимое 32 бита.
да не так уж сильно, раза в полтора в среднем (и это для полностью программной реализации!)
зато очень быстрое умножение, которое нужно намного чаще, в том числе неявно (адрес в массиве)
Писал деление для Арма, чтобы получилось максимально быстро. Получилось примерно за 100 тактов, почти в три раза медленнее 80386 и при том меньшем делимом. Eсли ограничить делитель 16 битами, то 80286 обгонит Арм почти в 5 раз. Возможно есть и более быстрые деления для ARM2, но мне такие не встречались.
По умножению Арм2 скорее нетороплив, от 2 до 17 тактов, и это только полуумножение без старшего слова. 80386 с полным умножением от 9 до 38. Таким образом, полное умножение у Арм только незначительно быстрее 80386 и гораздо больше по коду.
а с вызовом универсальной (или частных случаев) процедуры - меньше!Повторю, не спортивно.
трюки есть и менее сложные (например, прочесть пачку аргументов одной командой там, где 386 вынужден уныло копаться в стеке) и результаты следует оценивать комплексноЭто очень редкий случай и, пожалуй, единственный. Повторю, параметры сейчас передают через регистры, а через стек только добавочные, если регистров не хватает.
совершенно к делу не относящиесяГоворим о плотности кодов, дал вам ссылку по исследованиям по плотности кодов, а вы - это к делу не относится?!
см. выше - дохренища я написал и специализация надоелаВозможно, это дело вкуса. Мне она не мешала. Там даже интересно, все регистры с именами АХ - аккумулятор, ВХ - базовый, СХ - счетчик, DX - данные, SI - источник, DI - приемник. В Интеле работали с воображением, не пpосто циферки для регистров делали как 68к, PDP11 или ARM. :)
во-1 не в три раза, а от силы в два, иначе прямые спектрумовские порты так заметно на комоде не тормозили бы (в отличие портов на атари с его как раз ровно вдвое меньшей частотой камня); во-2, пример 6502 подтверждает как раз обратное, потому что он вообще не мог работать на таких частотах, чтобы догнать, будучи привязанным к памяти; в-3, если память не ограничивает скорость проца вообще, то она регистрами и является (потому что даже кэш на одном кристалле даёт задержки)
У Коммодора менее мегагерца, поэтому если считать 6502 в 2.5 раза шустрее, то отставание от спека на 40%, а в Атарях процентов 30-40% частоты штатно съедало видео - поэтому и там имеем те же 2.5 раза. 6502 нужна была память побыстрее и с этим были проблемы, но дело портилось ещё тем, что почти все или даже все компы на 6502 использовали память одновременно для видео и процессора, что очень снижало скорость, и требовало в 2 РАЗА более быстрой памяти, чем процессор. А у Спека была быстрая память, без тормозов. Но 6502 работал с памятью как с регистрами, не тормозя, такт на обращение. В когда-то популярном в Штатах TI-99, процессор вообще не имел регистров - если память не тормозит, то это очень неплохое решение.
:v2_dizzy_tired2: в возне со стеком (но да, на x86 это не "проблема", там это жизнь)))Обычно в стеке лежат локальные переменные и к ним обращаются индивидуально и тут у Арм никаго преимущества. Часть локальных переменных иногда перемещают в регистры для оптимизации, что дает место командам массовой загрузки регистров. Однако, оптимизация штука очень хитрая и не уверен, что массовая загрузка всегда пойдет, например, нужно оптимизировать переменные не подряд, а через раз.
точно, XCHG нету :v2_dizzy_biggrin2: есть EXG - обмен между регистрами; и между половинками регистра данных (SWAP называется) :v2_dizzy_botan:Точно. Попутал меня 8086, где для обоих случаев XCHG. А SWAP действительно хорошая вещь, сильно помогает для кодов 68000.
а я писал, что и в арифметике подойдутСкорее в полуарифметике, так как там даже флаги не ставятся и добавлять/отнимать можно только слова.
для КАКИХ? в вычислениях применять их можно только парой, только для логики
что ни гибче, ни тем более "существенно" гибчеВы можете грузить сразу пары байт, обрабатавать их по одному и раскидывать также в разные места - 68000 так не умеет, несмотря на большую регистровую память.
то есть "отличный ММЮ" раньше было в смысле "Хопёр-Инвест отличная компания (от других)"? :v2_laugh:Отличный (очень хороший) для специальных случаев. :)
чувствуется закономерность результата :v2_dizzy_biggrin2:Нет там защиты памяти.
ага, бизнес дона Интелоне - сломать ногу и предложить костыль как "удобство" :v2_clap2:У других было ещё хуже, там сразу два, а иногда и три костыля шли в комлекте. :)
- - - Добавлено - - -
И всё нормально считается. Ну кроме случая, когда программа занимает всю память
Вот набрал пример в RSX-11 - не работает.
.MAIN. MACRO V05.05 Monday 24-FEB-20 11:33 Page 1
1 .mcall exit$s
2 000000 start:
3 000000 012700 000004' mov #b,r0
A 4 037174 a = 16000.-.
5 000004 b: exit$s
6 000000' .end start
.MAIN. MACRO V05.05 Monday 24-FEB-20 11:33 Page 1-1
Symbol table
A = ****** B 000004R START 000000R
. ABS. 000000 000 (RW,I,GBL,ABS,OVR)
000012 001 (RW,I,LCL,REL,CON)
Errors detected: 1
*** Assembler statistics
Work file reads: 0
Work file writes: 0
Size of work file: 201 Words ( 1 Pages)
Size of core pool: 9260 Words ( 35 Pages)
Operating system: RSX-11M/M-PLUS
Что за ерунда? Откуда опять ядро?! Вам про то, что вы тут RSX-11 якобы продвигаете, а сами втихомолку являетесь поклонником RT-11. Про числа написал ясно - любые.
Вот набрал пример в RSX-11 - не работает.
Программирование на MACRO-11 подучите - и заработает
LOGIN.CMD;1 ! 2!LOGIN.CMD
! !MOUDISKS.CMD
! !
! 1!DU1:[BATCH]MICROS.DIR
! 3!DU1:[ACD2]MICROS.DIR
... ! !TEST.MAC
! !TMP.LST
[* КОНЕЦ ТЕКСТА *]
MCR > TYP TMP.LST
TEST MACRO V05.05 Monday 2020-02-24 14:43 Page 1
1 .TITLE TEST
2 .MCALL EXIT$S
3 000000 .ASECT
4 001000 .=1000
5 001000 012700 001004 START: MOV #B, R0
6 036174 A = 16000.-.
7 001004 B: EXIT$S
8 001000 .END START
TEST MACRO V05.05 Monday 2020-02-24 14:43 Page 1-1
Symbol table
A = 036174 B 001004 START 001000
. ABS. 001012 000 (RW,I,GBL,ABS,OVR)
000000 001 (RW,I,LCL,REL,CON)
Errors detected: 0
*** Assembler statistics
Work file reads: 0
Work file writes: 0
Size of work file: 201 Words ( 1 Pages)
Size of core pool: 13506 Words ( 51 Pages)
Operating system: RSX-11M/M-PLUS
Elapsed time: 00:00:00.01
TEST;1,TMP;1/-SP/NL:TTM=TEST
MCR >
А макрос вы теперь очевидно и сами не знаете как делать. Как и писал, несколько лет назал знающие люди на БК форуме (среди них возможно и вы были) искали и не нашли.
Не было меня там, потому что мне искать не надо - я знаю, как сделать. Но с учётом того, что никакого выигрыша на этом не получить - смысла показывать как - не вижу. Ломайте голову дальше, вдруг осенит - новые знания, добытые самим - полезней готовых решений
- - - Добавлено - - -
Возьмем типичную команду загрузки из памяти MOVE data(a3),d0. В этой команде a3 - база, а data - это 16-БИТНОЕ смещение
data - база, а a3 смещение
- - - Добавлено - - -
Там даже интересно, все регистры с именами АХ - аккумулятор, ВХ - базовый, СХ - счетчик, DX - данные, SI - источник, DI - приемник. В Интеле работали с воображением, не пpосто циферки для регистров делали как 68к, PDP11 или ARM.
И не дай бог не тот регистр для операции использовать. А в PDP-11 - можно любой (кроме MUL и DIV). И если уж сильно захочется - можно регистры и переименовать. Так что для x86 - в минус запишем
- - - Добавлено - - -
Отличный (очень хороший) для специальных случаев.
А на PDP-11 - отличный для любых случаев
Не было меня там, потому что мне искать не надо - я знаю, как сделать. Но с учётом того, что никакого выигрыша на этом не получить - смысла показывать как - не вижу. Ломайте голову дальше, вдруг осенит - новые знания, добытые самим - полезней готовых решений
От жадности не лопните. Мне-то это только для архива, не особо и нужно. Хотите схоронить, дело ваше. Но вроде вы же из МГУ, вроде как святоч премудростей - должны просветлять народ. И это форум, не приватный разговор - тут не только мы с вами. Хотя уверен, что сами не знаете.
data - база, а a3 смещениеКакая чушь! У меня переменные называются data, data2, ...
И не дай бог не тот регистр для операции использовать. А в PDP-11 - можно любой (кроме MUL и DIV). И если уж сильно захочется - можно регистры и переименовать.
И низачем это не нужно, вот в х86 всё гораздо лучше. Нужен счетчик (counter) берем CX, нужна база - BX и т. д. - просто совершенство почти и не надо пространство кодов захламлять излишними индексами ронов как это сделано в почти ортогональных ассемблерах. Ортогональность - это тяжкое наследие 70-х, подражание которому сгубило Моторолу. В ПДП-11 R5 и R6 тоже вроде как обычные регистры с номерами, но нормально все-таки писать SP и PC - Интел научило как правильно.
А на PDP-11 - отличный для любых случаевТолько для одного, для потерявшихся во времени некоторых расейских магазинах. А по честному - это начавшая устаревать с начала 80-х система, устаревшая полностью к началу 90-х.
И это форум, не приватный разговор - тут не только мы с вами.
И это должно меня волновать?
Какая чушь!
Чушь пока вы порете
Нужен счетчик (counter) берем CX, нужна база - BX и т. д
Шаг вправо-влево - расстрел на месте, прыжок - попытка улететь. Нравится программировать в узких рамках - ваши проблемы
. А по честному - это начавшая устаревать с начала 80-х система, устаревшая полностью к началу 90-х.
Так чего вы к ней лезете - забудьте как страшный сон.
Lethargeek
24.02.2020, 21:29
Возьмем типичную команду
А ну стоп! Хватит уходит от ответа! :v2_dizzy_stop: Вопрос был не про "типичные команды", а про КОНКРЕТНЫЙ код - где гарантия, что в ds будет нужное значение перед вызовом?
типичную команду загрузки из памяти MOVE data(a3),d0. В этой команде a3 - база, а data - это 16-БИТНОЕ смещение,
Таким способом адресуются типичные структуры с известными заранее смещениями, и на них вполне хватает даже менее 16 бит.
если вам нужны данные, которые не влазят в 64 КБ (например, data2), то базу надо менять. Это абсолютно аналогично ситуации с х86.
Если мне нужны такие большие данные, то и базы для интересующего куска, и смещения для них будут вычисляться в регистрах, и вот здесь у 16-битных x86 абсолютно НЕаналогично начинаются проблемы и тормоза.
Ничего не понял. Повторю, что естественно все данные небольшого размера держать в DS. А во времена дефицита памяти, когда даже 512 КБ было очень много, это было более чем нормально. Что тут не так? Если вы про CS, то меняя его легко получаем 1 МБ для подпрограмм, которые используют один и тот же DS. И тут что для вас не так? Два типа подпрограмм тяжело использовать?
Повторю: где гарантия, что перед вызовом процедуры распечатки значения ds не испорчен типичной процедурой доступа к большому массиву (из которого, скорей всего, и берутся эти числовые данные для печати)?
Извините, но никак не пойму. Может скажете более конкретно, что именно вам не понраравилось в приведенных кодах?
cферовакуумное самозарождение входных параметров сразу же в удобных регистрах
У меня получилось для АРМа 16 тактов, а для 8086 более 300.
я оценивал для арма с динамической памятью
Деление на 8086 выполняется за разное число тактов для разных аргументов, поэтому подсчитать точное число тактов очень непросто и неоднозначно.
144...162 относительно небольшой разброс, если даже только минимум брать, то картина практически не изменится
Это, как говорят, не спортивно.
неспортивно убирать из процедуры часть процедуры
универсальное 32-битное деление на 80286 - это примерно 51 такт, специализированное деление на 10 у Арма - это 40 тактов.
:v2_dizzy_facepalm: 40 БАЙТ, но только 10 ТАКТОВ! и ведь только что сам же говорил про 16 тактов на ИТЕРАЦИЮ...
Получаем 51/40 = 1.275, т.е. выигрыш Арма на примерно четверть. Если в универсальном делении использовать делитель 10, то для 80286 получим уже примерно 64 такта. В этом случае получаем 64/40 = 1.6 и опять и близко не 3.6
я для полной итерации подсчитал - 72 такта 286 против ~20 армовских
универсальное 32-битное деление на 80386 - это 38 тактов - обгонит и на той же частоте.
да что ж такое то! снова растечение мысью :v2_dizzy_tired2:
для вот этого конкретного примера - НЕТ, НЕ обгонит!
Универсальное 32-битное деление на 80386 - это одна команда от 2 до 4 байт, на Арме, если делать побыстрее без циклов, то более 200 байт,
да и пофиг, сколько там займёт ПРОЦЕДУРА, многократно вызываемая в коде ОДНОЙ командой
причём сам вызов процедур таких на арме довольно "дешёв", по сравнению даже с 386
И это про Арм-варианты, когда делимое 32 бита. На 80386 оно 64 бита. На 80286 и 8086 делимое 32 бита.
На x86 длинное делимое в 99.9% случаев нахрен никому не сдалось, ибо требует дополнительных проверок на возможную ошибку переполнения или перехвата прерывания по ошибке. Для 286 еще проверки имеют смысл (сам писал быстрое 32-битное деление для Форта), но для 386 в edx тупо пишут ноль или расширение знака.
Писал деление для Арма, чтобы получилось максимально быстро. Получилось примерно за 100 тактов, почти в три раза медленнее 80386 и при том меньшем делимом. Eсли ограничить делитель 16 битами, то 80286 обгонит Арм почти в 5 раз. Возможно есть и более быстрые деления для ARM2, но мне такие не встречались.
мне встречались цифры 32...116 с утверждением, что средневзвешенно меньше среднего
и процедуры с ограничением делителя тоже побыстрее будут наверняка
По умножению Арм2 скорее нетороплив, от 2 до 17 тактов, и это только полуумножение без старшего слова.
См. выше - длинный результат разве что немногим чаще длинного делимого нужен (при расчёте 32-битных адресов никогда не нужен). Как-то с толком применять его потом затруднительно, разве что для */ операций (но опять же, требуются проверки, да и для арма комбинацию */ можно реализовать быстрее суммы двух процедур)
80386 с полным умножением от 9 до 38. Таким образом, полное умножение у Арм только незначительно быстрее 80386 и гораздо больше по коду.
НЕТ, "таким образом" наиболее востребованное умножение у арма в лучшем случае быстрее в 4.5 раз, в худшем - быстрее в 2.2+ раз, а в среднем - быстрее в 2.47+ раз. Ничего себе "незначительно"! Причём худшего случая на арме легко избежать ценой одной проверки и всего двух лишних тактов, тогда в среднем выйдет почти в 3 раза.
Это очень редкий случай и, пожалуй, единственный. Повторю, параметры сейчас передают через регистры, а через стек только добавочные, если регистров не хватает.
Ахахах! Очень редкий? :v2_laugh: Да это именно что типичный в армах способ доступа к любой структуре небольшого размера. Например, прочитали разом 6 координат треугольника, рассчитали поворот, записали разом обратно. Сортировка - прочитали несколько значений, отсортировали в регистрах, записали разом обратно, переходим к следующему куску. Все куски прошли - дальше будет проще с ними работать, начиная с крайних значений. Распаковка, включая кодеки - из потока тянем биты в несколько регистров, насколько хватит. И так далее.
Говорим о плотности кодов, дал вам ссылку по исследованиям по плотности кодов, а вы - это к делу не относится?!
нет, мы говорили там не о плотности, а о том, ЗАЧЕМ НА САМОМ ДЕЛЕ придуман палец
причём, кстати, даже с разрешённым пальцем код для армов генерится всё-таки смешанный
Возможно, это дело вкуса. Мне она не мешала. Там даже интересно, все регистры с именами АХ - аккумулятор, ВХ - базовый, СХ - счетчик, DX - данные, SI - источник, DI - приемник. В Интеле работали с воображением, не пpосто циферки для регистров делали как 68к, PDP11 или ARM.
ага, имена профессий, чтобы отличить сапожника от пирожника, и не ошибиться с заказом
только это признак недостатка, а не достоинства
У Коммодора менее мегагерца, поэтому если считать 6502 в 2.5 раза шустрее, то отставание от спека на 40%, а в Атарях процентов 30-40% частоты штатно съедало видео - поэтому и там имеем те же 2.5 раза.
нет, не сходится - тогда атари был бы не быстрей комода (для которого основное торможение от видео в этот мегагерц не входит) в портах со спектрума, а он всё-таки заметно быстрее (а комод - медленнее спека явно не всего на 40%)
6502 нужна была память побыстрее и с этим были проблемы, но дело портилось ещё тем, что почти все или даже все компы на 6502 использовали память одновременно для видео и процессора, что очень снижало скорость, и требовало в 2 РАЗА более быстрой памяти, чем процессор. А у Спека была быстрая память, без тормозов. Но 6502 работал с памятью как с регистрами, не тормозя, такт на обращение.
Нееет, как раз всё ровно наоборот - 6502 работает ПОСТОЯННО ТОРМОЗЯ до уровня памяти :v2_tong:
В когда-то популярном в Штатах TI-99, процессор вообще не имел регистров - если память не тормозит, то это очень неплохое решение.
тот еще уродец, дорогой быстрой памяти в котором кот наплакал только для замены регистров
Обычно в стеке лежат локальные переменные и к ним обращаются индивидуально и тут у Арм никаго преимущества.
это интелострадальцы должны страдать, потому что просто деваться некуда, а рискобоярам необязательно - в том и состоит преимущество :v2_dizzy_roll:
Часть локальных переменных иногда перемещают в регистры для оптимизации, что дает место командам массовой загрузки регистров. Однако, оптимизация штука очень хитрая и не уверен, что массовая загрузка всегда пойдет, например, нужно оптимизировать переменные не подряд, а через раз.
оптимизация формата исходных данных - часть оптимизации в целом
Скорее в полуарифметике, так как там даже флаги не ставятся и добавлять/отнимать можно только слова.
не помню про флаги, но если в старших разрядах адресного нули, то какая разница
Вы можете грузить сразу пары байт, обрабатавать их по одному и раскидывать также в разные места - 68000 так не умеет, несмотря на большую регистровую память.
ага! тут мы сразу вспоминаем, что данные из памяти грузить надо! а как код для x86 - так сразу "типично передавать в регистрах" :v2_clap2:
Отличный (очень хороший) для специальных случаев.
для каких-то очень уж "специальных" (как "особенный ребёнок" политкорректно)))
Нет там защиты памяти.
а многозадачность есть искаропки - видать, был приспособлен лучше "очень хороших" :v2_dizzy_biggrin2:
У других было ещё хуже, там сразу два, а иногда и три костыля шли в комлекте.
пхе, явно не у арма с 68000
Так чего вы к ней лезете - забудьте как страшный сон.
Трудно мне вас понять. Откуда такие суждения? Была системка, в чем-то неплохая. В чем проблема?
А ну стоп! Хватит уходит от ответа! :v2_dizzy_stop: Вопрос был не про "типичные команды", а про КОНКРЕТНЫЙ код - где гарантия, что в ds будет нужное значение перед вызовом?
Таким способом адресуются типичные структуры с известными заранее смещениями, и на них вполне хватает даже менее 16 бит.
Если мне нужны такие большие данные, то и базы для интересующего куска, и смещения для них будут вычисляться в регистрах, и вот здесь у 16-битных x86 абсолютно НЕаналогично начинаются проблемы и тормоза.
Повторю: где гарантия, что перед вызовом процедуры распечатки значения ds не испорчен типичной процедурой доступа к большому массиву (из которого, скорей всего, и берутся эти числовые данные для печати)?
Всё, кроме последнего, непонятно про что. А в последнем явная ошибка. Зачем менять ds для массивов, для этого предназначен ES?
cферовакуумное самозарождение входных параметров сразу же в удобных регистрахТипа, что если регистров не очень много, то придется часть из них сохранять при вызове функции. Отчасти верно.
неспортивно убирать из процедуры часть процедурыЭто был типичный код. Возможно полный вызов с учетом сохранения регистров займет больше места на 8086, чем на 68000, но может и не займет.
да и пофиг, сколько там займёт ПРОЦЕДУРА, многократно вызываемая в коде ОДНОЙ командой
причём сам вызов процедур таких на арме довольно "дешёв", по сравнению даже с 386
Одна команда - это 4 байта и ещё 4 байта на возврат. На 80386 это типично 4 байта на обе команды.
На x86 длинное делимое в 99.9% случаев нахрен никому не сдалось, ибо требует дополнительных проверок на возможную ошибку переполнения или перехвата прерывания по ошибке. Для 286 еще проверки имеют смысл (сам писал быстрое 32-битное деление для Форта), но для 386 в edx тупо пишут ноль или расширение знака.
Отстаёте от жизни. Сейчас 64 бита - стандарт, а компиляторы нормальные уже 128 бит на целое предлагают.
мне встречались цифры 32...116 с утверждением, что средневзвешенно меньше среднего
и процедуры с ограничением делителя тоже побыстрее будут навернякаБуду очень благодарен на ссылку на такое супер-арм-деление. Мне не получилось найти ничего быстрее 100 тактов при 32-битном делителе. В пи-затворе для деления 32 бит на 16 получилось 54 такта в среднем, но это при том что у пи-затвора очень редко случается тормозной случай на 88 тактов. В настоящем среднем получилось бы 71 такт.
НЕТ, "таким образом" наиболее востребованное умножение у арма в лучшем случае быстрее в 4.5 раз, в худшем - быстрее в 2.2+ раз, а в среднем - быстрее в 2.47+ раз. Ничего себе "незначительно"! Причём худшего случая на арме легко избежать ценой одной проверки и всего двух лишних тактов, тогда в среднем выйдет почти в 3 раза.Расскажите такое тем, кто компиляторы пишет. Им будет смешно. Хотя, согласен, что у Арм больше возможностей для оптимизации, но это иногда требует кропотливой ручной работы, как в примере на вырисовку прямой. Хорошо для демок, но не для промышленных кодов.
Ахахах! Очень редкий? :v2_laugh: Да это именно что типичный в армах способ доступа к любой структуре небольшого размера. Например, прочитали разом 6 координат треугольника, рассчитали поворот, записали разом обратно. Сортировка - прочитали несколько значений, отсортировали в регистрах, записали разом обратно, переходим к следующему куску. Все куски прошли - дальше будет проще с ними работать, начиная с крайних значений. Распаковка, включая кодеки - из потока тянем биты в несколько регистров, насколько хватит. И так далее.
Это уже оптимизация. И примерно также можно работать и х86-64 - там 16 регистров, а у АРМ - 15. Кстати, команды по загрузке/выгрузке регистров в/из стека 1-байтовые, поэтому одна команда АРМ по загрузке данных займет столько, сколько 4 на х86. Конечно, в целом у Арм тут преимущество, но не огромное.
нет, мы говорили там не о плотности, а о том, ЗАЧЕМ НА САМОМ ДЕЛЕ придуман палец
причём, кстати, даже с разрешённым пальцем код для армов генерится всё-таки смешанный
Начали абстракто, что плотнее. А для чего Пальцы, это ваша тема, которую вы ничем кроме своего мнения не подтвердили.
ага, имена профессий, чтобы отличить сапожника от пирожника, и не ошибиться с заказом
только это признак недостатка, а не достоинстваА что их надо называть одинаково? Сапожник, спеки булку! :)
нет, не сходится - тогда атари был бы не быстрей комода (для которого основное торможение от видео в этот мегагерц не входит) в портах со спектрума, а он всё-таки заметно быстрее (а комод - медленнее спека явно не всего на 40%)
Торможение у Коммодора от видео небольшое, всего примерно 5%, а частота почти на 80% меньше, чем на Атарях. Но видео у Атари тормозное. В итоге, Атари на процентов сорок быстрее Коммодора. Что тут не так? 40% очень заметно в играх. С другой стороны, если переносить игры с С64 на Спектрум, то Спек тормозить может очень сильно при очень существенной потере качества.
Нееет, как раз всё ровно наоборот - 6502 работает ПОСТОЯННО ТОРМОЗЯ до уровня памяти :v2_tong:Повторю, на большинстве 6502 систем, память должна была быть быстрее процессора. Почитайте, например, про ВВС Micro в википедии - они там расписывают проблему доставания памяти на 4 МГц в 1980, при том, что процессор на 2 МГц.
тот еще уродец, дорогой быстрой памяти в котором кот наплакал только для замены регистровЭто из 70-х, памяти было в обрез. А если бы поставили нормальную память всю в 80-е, то получилось бы неплохо. Не зря IBM среди процессоров для РС серьёзно рассматривало и это, но им было мало адресуемости только 64 КБ.
это интелострадальцы должны страдать, потому что просто деваться некуда, а рискобоярам необязательно - в том и состоит преимущество :v2_dizzy_roll:
Опять вас не понял. В современных х86 регистров как и в Арм. Арм-64 - это отдельная тема.
не помню про флаги, но если в старших разрядах адресного нули, то какая разницаА при чем тут нули в старших разрядах? И не нули там, а что напишут.
ага! тут мы сразу вспоминаем, что данные из памяти грузить надо! а как код для x86 - так сразу "типично передавать в регистрах" :v2_clap2:Вы о разном, о вызове функций и загрузке данных.
а многозадачность есть искаропки - видать, был приспособлен лучше "очень хороших" :v2_dizzy_biggrin2:Многозадачность там как и под первыми виндузами - до запуска первой игры или даже демки. ;)
пхе, явно не у арма с 68000Зря вы их смешиваете. Арм - это достойный конкурент х86, который будь у Акорна больше ресурсов мог бы его существенно превзойти. 68к - скорее неудачное развитие технологий DEC, VAX - гораздо удачнее. Из 68к только 68000 получился реально конкурентным, но и он в себе содержал такие недостатки, что развивать его не получилось. А 68020/30 эти недостатки только усугубили. Хотя интересные тоже были процессоры, до сих пор где-то в контроллерах используют.
Про близость архитектур ARM и x86 идеям мейнфреймов Белоснежки - https://habr.com/ru/post/514096/
Lethargeek
26.09.2020, 14:22
снова ересь про "соединение risc и cisc" - один журналамер некогда ляпнул, а другие до сих пор повторяют :v2_dizzy_facepalm:
эти термины относиться могут только к МАКРОархитектуре, то есть к уровню ассемблера, доступному программисту
а на нём x86 как был всю историю чистейшим цыском, так и остался
- - - Добавлено - - -
не распарсил сразу про "два бита вместо привычных флагов"
вообще-то это те же самые флаги, просто смысл их от контекста зависит
что должно быть привычно кодерам Z80 с его контекстным флагом P/V
и далее по тексту мутно, то 2 бита, то 4, поди пойми
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot