Просмотр полной версии : Кросс-компиляция для програм на си
Один британец делает интересный проект - https://github.com/hoglet67/PiTubeDirect/wiki/PDP-11-Co-Pro-Notes - про 4 компилятора. Он получает в итоге код для почти голого железа на основе второго процессора для BBC Micro (эквивалент скорости до 500МГц на J11!). Подобные дела могут быть интересны, например, для БК и другого PDP-11 железа. Кромe того, мне представляется, что автор несколько усложняет работу с GCC, - может кто-то захочет ему что-то подсказать.
SuperMax
29.05.2022, 14:45
честно не совсем понял причем тут BBC Micro ? поясните суть
если речь идет о компиляции СИ для PDP-11 то в чем преимущества относительно уже готовых решений ? есть поддержка ДП ? под какие ОС собирается исполняемый файл ?
честно не совсем понял причем тут BBC Micro ? поясните суть
если речь идет о компиляции СИ для PDP-11 то в чем преимущества относительно уже готовых решений ? есть поддержка ДП ? под какие ОС собирается исполняемый файл ?
Готовые решения? К сожалению, возможно здесь малоинформирован. Знаю только, что среди энтузиастов не раз пробовали поработать с генерацией бинарников для БК через GCC.
Знаю ещё, что теоретически можно, используя си-компилятор на БК0011 (УКНЦ, ДВК, ...) под RT11, пытаться затем скомпоновать объектный файл, выдаваемый компилятором, в файл для исполнения на голом железе. Но с таким никогда не сталкивался.
Как и писал, это проект для голого железа, т.е. в точности для ситуации существования практически всего БК-софта. На BBC Micro с PDP11-процом так пока никакую ОС и не перенесли - британцам без нашей или американской помощи тут скорее не справиться.
Для меня в hoglet-проекте оказалось сюрпризом, что старый ACK поддерживается и генерирует правильные коды "прямо из коробки", не нужно всякого шаманства как с с GCC или PCC. Кроме того, и качество кодов у ACK для PDP-11 лучше и подстраивать его намного легче, чем GCC.
Сейчас есть немало софта (в основном игр) для кросс-платформенной си-компиляции. Для 6502 есть cc65, для 8080 и Z80 - z88dk. Весь этот софт можно сделать доступным для БК, если написать библиотеки для поддержки графики и звука, которые скорее всего где-то уже есть.
На BBC Micro с PDP11-процом это что за зверь?
SuperMax
29.05.2022, 22:08
Готовые решения? К сожалению, возможно здесь малоинформирован. Знаю только, что среди энтузиастов не раз пробовали поработать с генерацией бинарников для БК через GCC.
Знаю ещё, что теоретически можно, используя си-компилятор на БК0011 (УКНЦ, ДВК, ...) под RT11, пытаться затем скомпоновать объектный файл, выдаваемый компилятором, в файл для исполнения на голом железе. Но с таким никогда не сталкивался.
Как и писал, это проект для голого железа, т.е. в точности для ситуации существования практически всего БК-софта.
для какого именно ?
На BBC Micro с PDP11-процом так пока никакую ОС и не перенесли - британцам без нашей или американской помощи тут скорее не справиться.
прошу пруф на этого зверя
ибо даже в вики указано
https://ru.wikipedia.org/wiki/BBC_Micro
Процессор: MOS Technology 6502A (в Model B — 6512A) на тактовой частоте 2 МГц
Для меня в hoglet-проекте оказалось сюрпризом, что старый ACK поддерживается и генерирует правильные коды "прямо из коробки", не нужно всякого шаманства как с с GCC или PCC. Кроме того, и качество кодов у ACK для PDP-11 лучше и подстраивать его намного легче, чем GCC.
Сейчас есть немало софта (в основном игр) для кросс-платформенной си-компиляции. Для 6502 есть cc65, для 8080 и Z80 - z88dk. Весь этот софт можно сделать доступным для БК, если написать библиотеки для поддержки графики и звука, которые скорее всего где-то уже есть.
честно, очень плохо представляю работу с графикой через графические библиотеки на БК, как впрочем и на других вышеуказанных машинах. принципы работы с графикой у спектрума и БК отличаются кардинально.
это что за зверь?
https://mdfs.net/Docs/Books/PDP11CoPro/Technical
Мне известны, как минимум, три реализации с примерно 2010. Сделали примерно несколько сотен штук. Но из софта есть только ВВС бейсик и несколько простых утилит. Это подгревает интерес к кросс-компиляции.
для какого именно ?
Такого что на любом БК запускается, или игры и много чего ещё для 0011.
прошу пруф на этого зверя
ибо даже в вики указано
https://ru.wikipedia.org/wiki/BBC_Micro
Процессор: MOS Technology 6502A (в Model B — 6512A) на тактовой частоте 2 МГц
Это основной процессор. Но везде также написано, что BBC Micro имеет фирменную фишку - слот для подключения 2-о процессора, куда повтыкали практически все известные процы. При подключении 2-го процессора, основной проц превращается во вспомогательный для работы с графикой и вводом-выводом. Кстати, Коммодор хотел у них купить эту фишку, но те пожадничали - пришлось Коммодору что-то такое изобрести только на Амиге 1200.
честно, очень плохо представляю работу с графикой через графические библиотеки на БК, как впрочем и на других вышеуказанных машинах. принципы работы с графикой у спектрума и БК отличаются кардинально.
Это зря. Вот список уже поддерживаемых платформ - https://github.com/z88dk/z88dk/wiki/Platform - на некоторых графика очень экзотичная. На БК графика очень простая, существенно попроще, чем, например, на Амстраде или Векторе. Вот Корвет хорошо туда сделать - это реально крутая задачка.
SuperMax
04.06.2022, 12:09
https://mdfs.net/Docs/Books/PDP11CoPro/Technical
Мне известны, как минимум, три реализации с примерно 2010. Сделали примерно несколько сотен штук. Но из софта есть только ВВС бейсик и несколько простых утилит. Это подгревает интерес к кросс-компиляции.
где можно посмотреть прочитать подробно?
если говорить о том что подрывает интерес то это:
1. экзотичность платформы BBS
2. вместо стандартного MACRO-11 они изобретают свой ассемблер с неведомыми параметрами - ну к примеру
MOV #&FFFE,R0 ; Read/Write Escape handler
ADR MyEscHandler,R1 ; Set Escape handler address
ADR MyEscFlag,R2 ; Set Escape flag address
EMT 14
MOV R1,OldEscHandler ; Save old address
MOV R2,OldEscFlag ; Save old address
Такого что на любом БК запускается, или игры и много чего ещё для 0011.
я так и не увидел ответов на простые вопросы:
есть поддержка ДП ? под какие ОС собирается исполняемый файл ?
если речь о компиляторе СИ который не поддерживает ДП и не способен сделать файл под операционную систему то какой в этом смысл ?
лично мне был бы ОЧЕНЬ интересен компилятор СИ который выдаст исполняемый файл под SJ монитор, но с поддержкой ДП - те возможностью использовать до 4хМБ оперативки втч и сам будет заниматься поддержкой оверлея
Это основной процессор. Но везде также написано, что BBC Micro имеет фирменную фишку - слот для подключения 2-о процессора, куда повтыкали практически все известные процы. При подключении 2-го процессора, основной проц превращается во вспомогательный для работы с графикой и вводом-выводом. Кстати, Коммодор хотел у них купить эту фишку, но те пожадничали - пришлось Коммодору что-то такое изобрести только на Амиге 1200.
Это зря. Вот список уже поддерживаемых платформ - https://github.com/z88dk/z88dk/wiki/Platform - на некоторых графика очень экзотичная. На БК графика очень простая, существенно попроще, чем, например, на Амстраде или Векторе. Вот Корвет хорошо туда сделать - это реально крутая задачка.
а смысл ?
Вообще-то кросс-компиляция это всего лишь навсего получение исполняемых кодов для какой-либо архитектуры на другой архитектуре. Обычно имеет смысл это делать на более мощной для менее мощной, иногда на равноценной.
Здесь же, насколько я Вас понял задача более сложная. Исполняемые коды одной архитектуры преобразовать в коды более мощной( не имея исходников этих кодов). Даже если упростить эту задачу и давать более мощному процессору( я его в этом случае всегда называл процедурным сопроцессором) выполнять только "железо-независимые" фрагменты кода, так как он может иметь доступ только к памяти( а не портам ввода/вывода и/или системе прерываний), то все-равно это более сложная задача, чем обычная кросс-компиляция.
В этой системе должны быть части, характерные для эмулятора основной системы, чтобы выявлять "медленные фрагменты" кода, они дизассемблируются для основного процессора и конвертируются в ассемблер процедурного процессора. Затем ассемблируются его процессором. Можно обойтись и без дизассемблирования и ассемблирования, но тогда неимоверно возрастет сложность контроля для пользователя.
Мысль сделать из PDP-11 процедурный процессор имела бы смысл для архитектуры PDP-8.
ВВС-Micro логично использовать для этих целей современные и не очень ARM-процессоры.
Но в приведенном вами примере они использовали целый компьютер Pi-Zero, который в состоянии проделывать всё вышеописанное "на лету". "Фишка" здесь другая. Пользователь основного компа BBC-Micro остается в привычной операционной среде, а ее производительность и другие возможности увеличиваются, благодаря Pi-Zero. Такую штуку можно попытаться проделать для других старых компьютеров, в том числе и БК, но только изменив(дописав) ПО в Pi-Zero.
Графику таким способом сильно улучшить не получится на уровне железа. А вот матричные вычисления, необходимые для многих графических процедур, становятся более быстрыми и с большими возможностями. Поэтому для пользователя эффект улучшения присутствует.
- - - Добавлено - - -
1. экзотичность платформы BBС она просто, как пример. Можно попробовать такую же штуку с ZX Spectrum 48, Корветом, MSX.
где можно посмотреть прочитать подробно?
Документации немного, все-таки это поздний хоббистский проект. Вот несколько ссылок
https://mdfs.net/Software/Tube/PDP11/
https://beebwiki.mdfs.net/PDP-11_Second_Processor
есть ещё блоги с деталями разных частностей. Сам просто это гуглю - это может каждый. :) Если есть конкретные вопросы, могу задать их разработчикам.
если говорить о том что подрывает интерес то это:
1. экзотичность платформы BBS
Почему экзотичность? ВВС Мicro - это довольно известный компик. Его ОС перешла на Архимеды и её до сих пор поддерживают для всех Малинок Пи. Экзотично только использование некоторых процов, типа для PDP-11. Кстати, они поддерживают проц на уровне нашего ВМ2.
2. вместо стандартного MACRO-11 они изобретают свой ассемблер с неведомыми параметрами - ну к примеру
MOV #&FFFE,R0 ; Read/Write Escape handler
ADR MyEscHandler,R1 ; Set Escape handler address
Это только из-за того, что архитектура BBC Micro и ВВС бейсик изначально и до сих пор очень связаны. А человек, который имеет в мире BBC Micro авторитет и который портировал этот бейсик на PDP-11, который, кстати, успешно запускается на БК0011 или УКНЦ, использовал собственноручно написанный ассемблер, в котором совмещал штучки из мира 6502 и PDP-11. Британцы только недавно стали пытаться добавить больше софта, начали с си, но заметили и Макро-11. Интересно, что и у нас сейчас для БК тоже продвигают альтернативный ассемблер на питоне. :)
я так и не увидел ответов на простые вопросы:
есть поддержка ДП ? под какие ОС собирается исполняемый файл ?
Про ДП в точности не знаю, там должно быть явно больше чем 64 КБ, но в документации ничего не нашел. А про ОС писал уже несколько раз - собирают исполнимые файлы для голого металла, всё как на БК.
если речь о компиляторе СИ который не поддерживает ДП и не способен сделать файл под операционную систему то какой в этом смысл ?
Компилятор ДП и не должен в нашей ситуации поддерживать, в железе PDP-11 проца возможно есть поддержка страничной работы с памятью. Смысл в том (повторю), что есть немало софта, который при наличие этого компилятора и библиотеки легко переносится на БК. Вот, например, один из проектов такого типа - https://github.com/Fabrizio-Caruso/CROSS-LIB - у автора есть желание расширять поддержку PDP-11, ему нужны именно кросс-компилятор и библиотека.
лично мне был бы ОЧЕНЬ интересен компилятор СИ который выдаст исполняемый файл под SJ монитор, но с поддержкой ДП - те возможностью использовать до 4хМБ оперативки втч и сам будет заниматься поддержкой оверлея
Поддержку ДП делаем библиотечными функциями, пишем проги, использую соответствующие RT11 вызовы и соглашения - и какие проблемы?! Сделать формат исполнимого файла правильным - это несложно, такое уже делали.
Здесь же, насколько я Вас понял задача более сложная. Исполняемые коды одной архитектуры преобразовать в коды более мощной( не имея исходников этих кодов). Даже если упростить эту задачу и давать более мощному процессору( я его в этом случае всегда называл процедурным сопроцессором) выполнять только "железо-независимые" фрагменты кода, так как он может иметь доступ только к памяти( а не портам ввода/вывода и/или системе прерываний), то все-равно это более сложная задача, чем обычная кросс-компиляция.
Похоже Вы неправильно что-то поняли. Никакие коды преобразовывать не надо. Кросс-компилятор сразу генерирует правильные коды для целевой архитектуры.
ДОПОЛНЕНИЕ. Уточнил у британцев, в их системе поддерживается только 64 КБ, ДП нет.
- - - Добавлено - - -
"Фишка" здесь другая. Пользователь основного компа BBC-Micro остается в привычной операционной среде, а ее производительность и другие возможности увеличиваются, благодаря Pi-Zero. Такую штуку можно попытаться проделать для других старых компьютеров, в том числе и БК, но только изменив(дописав) ПО в Pi-Zero.
Это не так. Мне эти системы неплохо знакомы, даже исправил баг в эмуляции 32016 в b-em. Среда может меняться, но как правило они её делали близкой к типовой для BBC Micro. Если нужна только скорость, то второй проц - это 6502 на хорошей частоте. Другие процы (Z80, x86, PDP-11, ...) используют для запуска соответствующего софта (CP/M, MS-DOS, Panos, ...).
используют для запуска соответствующего софта (CP/M, MS-DOS, Panos, ...).
тогда биос/монитор тоже надо переписывать под BBC, так как без этого указанные Вами операционки правильно работать не будут.
Кросс-компилятор сразу генерирует правильные коды для целевой архитектуры.
каким образом? Если нет исходников, то кросс-компилятор ничего сгенерить не может! Декомпилировать исполняемый код до исходного текста С это надо умудриться(особенно, если исполняемый код получен не из С). Мне такие софты не попадались. Просто дизассемблировать(желател но с трассировкой и частями от эмулятора) и потом ассемблировать кросс-ассемблером это еще куда ни шло.
По поводу использования второго более скоростного 65c02 без внесения изменений в софт, а тем более для распараллеливания "на лету" тоже не получится для софта, который использовал первый процессор "под завязку". А вот расширенный по возможностям процессор, например, ARM с такой задачей справится может.
Если 65с02 в fpga, то его естественно можно расширить и ускорить(и замедлить). Тогда достаточно просто выкинуть или отключить основной процессор в плате и его функции, в том числе расширенные передать fpga-железу ( или как в проекте, на который Вы давали ссылку, компьютеру Pi Zero)
Если нет ни того, ни другого, в этой роли может выступить даже внешний гаджет( смартфон, наладонник, ноутбук, десктоп). По сути это режим ICE In-circuit emulation через CPU, а можно и через память. Тогда правда скорость не растет, но на BBC можно запускать что угодно.
тогда биос/монитор тоже надо переписывать под BBC, так как без этого указанные Вами операционки правильно работать не будут.
Дело в том, что СР/М для BBC Micro существуют в двух вариантах с первой половины 80-х. Оба варианта были весьма недёшевы, но работают отлично. Сам под них писал коды. Второй Z80 процессор от Acorn работает на 6 МГц без тормозов - это одна из самых быстрых машинок на Z80. А второй Z80 от Torch использует своё ПЗУ и поэтому СР/М там грузится быстро, потом так на Маках и Амигах сделали. Также отлично работает ДОС на https://en.wikipedia.org/wiki/BBC_Master#Master_512 - тоже коды туда писал. :) То же самое верно и для Panos/Pandora или ArthurOS (предшественник RiscOS). Если кто захотел бы сгенерировать RT-11 проблем было бы не больше, чем для БК0011: исходники ОС есть, конфигурируем их, затем пишем драйвер дисковода на основе имеющихся, навешиваем эмулятор терминала - и готово.
каким образом? Если нет исходников, то кросс-компилятор ничего сгенерить не может! Декомпилировать исполняемый код до исходного текста С это надо умудриться(особенно, если исполняемый код получен не из С). Мне такие софты не попадались. Просто дизассемблировать(желател но с трассировкой и частями от эмулятора) и потом ассемблировать кросс-ассемблером это еще куда ни шло.
Вы совсем похоже не поняли, о чем пишу. Не о каких декомпиляциях даже представить в этом контексте мне не представляется возможным. Попробую короче. Есть набор игр от Фабрицио, их народ может запускать на множестве платформ, включая наш Вектор. Исходники игр написаны на чистом си, языке высокого уровня. У Фабрицио есть базовая поддержка PDP-11, для переноса игр на БК нужны ещё компилятор и библиотека. Хоглет, об этом собственно весь мой пост, обнаружил, что в качестве компилятора, генерирующего PDP-11 коды, отлично работает ACK...
По поводу использования второго более скоростного 65c02 без внесения изменений в софт, а тем более для распараллеливания "на лету" тоже не получится для софта, который использовал первый процессор "под завязку". А вот расширенный по возможностям процессор, например, ARM с такой задачей справится может.
Но в реальности люди просто преобретали второй 6502 процессор и автоматически получали хороший разгон - это легко проверить на эмуляторах. Базовая ОС BBC Micro (биос фактически) учитывает наличие второго процессора и работает прозрачно для прикладных программ. Конечно, если прикладная программа будет работать не через системные вызовы, а прямым использованием аппаратуры, то она на втором процессоре не заработает - у каждого процессора память отдельная.
Дело в том, что СР/М для BBC Micro существуют в двух вариантах с первой половины 80-х.
Я не об этом. А о том, чтобы запустить на 65с02 исполняемый код[CP/M для z80 причем конкретного железа под него!] Конечно он эти коды должен воспринимать как данные для пересылки на параллельный процессор.
То есть у нас есть живой BBC микро, а вот того конкретного железа нет и в помине! И нет пзу его биоса/монитора-программы.
Ведь монитор-экран есть и клавиатура, и диски, но всё другое! Поэтому тот код, даже если "воткнуть" параллельно железный z80 правильно исполнятся не будет! А придется основному 65с02 перехватывать такие "железо-зависимые коды" и преобразовывать в свои собственные, чтобы пользователь мог видеть правильный результат на экране, а нажатие клавиш попадало в нужные яп параллельного процессора.
Об эмуляторах и говорить нечего! Если в него такую функцию специально не заложить.
То, что описываете Вы говорит о том, что на уровне схемы обе системы независимы и по команде пользователя разделяют общие ресурсы: диски, клавиатуру, монитор-экран. Это не параллелизм в исполнении кодов!
Но в реальности люди просто преобретали второй 6502 процессор и автоматически получали хороший разгон - это легко проверить на эмуляторах
значит основной софт допускал такое распараллеливание. В нынешних архитектурах тоже есть несколько ядер. Но старинному дос-у и windows-у их использовать для параллельных вычислений и даже для запуска разных задач в системе не удастся!
SuperMax
05.06.2022, 17:34
Документации немного, все-таки это поздний хоббистский проект. Вот несколько ссылок
Почему экзотичность? ВВС Мicro - это довольно известный компик.
возможно ТАМ, да. тут это дикий зверь которого никто и в глаза не видел.
Это только из-за того, что архитектура BBC Micro и ВВС бейсик изначально и до сих пор очень связаны.
честно не понял, причем тут бейсик-то ???? про бейсик давно пора забыть уже наконец!
А человек, который имеет в мире BBC Micro авторитет и который портировал этот бейсик на PDP-11, который, кстати, успешно запускается на БК0011 или УКНЦ, использовал собственноручно написанный ассемблер, в котором совмещал штучки из мира 6502 и PDP-11.
я очень рад за него и его авторитет, но лично мне это ничего не говорит.
Британцы только недавно стали пытаться добавить больше софта, начали с си, но заметили и Макро-11.
Интересно, что и у нас сейчас для БК тоже продвигают альтернативный ассемблер на питоне. :)
этот ассемблер тоже вещь в себе и как я не пытался его использовать - малоудобен. и что важно - не совместим со стандартом.
Про ДП в точности не знаю, там должно быть явно больше чем 64 КБ, но в документации ничего не нашел. А про ОС писал уже несколько раз - собирают исполнимые файлы для голого металла, всё как на БК.
и какой в этом смысл ?
Компилятор ДП и не должен в нашей ситуации поддерживать, в железе PDP-11 проца возможно есть поддержка страничной работы с памятью. Смысл в том (повторю), что есть немало софта, который при наличие этого компилятора и библиотеки легко переносится на БК. Вот, например, один из проектов такого типа - https://github.com/Fabrizio-Caruso/CROSS-LIB - у автора есть желание расширять поддержку PDP-11, ему нужны именно кросс-компилятор и библиотека.
Поддержку ДП делаем библиотечными функциями, пишем проги, использую соответствующие RT11 вызовы и соглашения - и какие проблемы?! Сделать формат исполнимого файла правильным - это несложно, такое уже делали.
вы похоже не поняли сути задачи
одно дело, я пишу программу на ассемблере и я точно знаю размер кода и исходя из этого могу переключать странички и прочее и совсем другое дело, когда я пишу на СИ, те на _другом_уровне_абстракции_ и тут я в принципе не знаю [и что важно - не хочу знать!] когда и как переключать страницы памяти. это задача компилятора собрать код так, и переключать страницы так, чтобы это работало. c поддержкой ОС тоже самое, это тоже задача.
ну вот я беру компилятор ТУРБОСИ и собираю код под XT и почему-то там мне никто не предлагает вручную передвигать указатели сегментных регистров ;-)
ДОПОЛНЕНИЕ. Уточнил у британцев, в их системе поддерживается только 64 КБ, ДП нет.
для меня интерес потерян.
я пишу программу на ассемблере и я точно знаю размер кода
когда я пишу на СИ, те на _другом_уровне_абстракции_ и тут я в принципе не знаю
Учитывая, что и на ассемблере (чаще всего) и на С (практически наверняка) будут подключаться всякие дополнительные модули и библиотеки, на этапе компиляции компилятору не будет известно - чего и сколько, а соотвественно - как переключать страицы ДП. Это може знать только линкер и менно он (и в RT и в RSX) умеет создавать оверлеи, резидентные в памяти. Если хочется делать это на этапе компиляции - придётся это делать руками.
Я не об этом. А о том, чтобы запустить на 65с02 исполняемый код[CP/M для z80 причем конкретного железа под него!] Конечно он эти коды должен воспринимать как данные для пересылки на параллельный процессор.
Параллельный - это неверно, процы не равны. Есть базовый и второй, опциональный. Если подключаем второй, то он берет управление на себя, а базовый (повторю) становится вспомогательным и управляет графикой, звуком, клавой и т.п. Поэтому если воткнуть Z80, то BBC Micro исполняет программы именно для Z80 без всякой пересылки кодов. Никакого конкретного железа кроме проца, интерфейса и памяти в плате второго процессора нет.
То есть у нас есть живой BBC микро, а вот того конкретного железа нет и в помине! И нет пзу его биоса/монитора-программы.
Ведь монитор-экран есть и клавиатура, и диски, но всё другое! Поэтому тот код, даже если "воткнуть" параллельно железный z80 правильно исполнятся не будет! А придется основному 65с02 перехватывать такие "железо-зависимые коды" и преобразовывать в свои собственные, чтобы пользователь мог видеть правильный результат на экране, а нажатие клавиш попадало в нужные яп параллельного процессора.
Так коды для железа у каждого компика свои, даже если процы одинаковые. Например, подобные коды для Спека, Амстрада или MSX совершенно разные. Их для каждой системы приходится писать, обычно это называют драйверами аппаратуры. Для 2-о процессора BBC Micro писать такие коды просто, вместо обращений к аппаратуре мы используем готовые системные вызовы. Для PDP-11 у нас есть готовые EMT-вызовы - в точности как и на БК.
То, что описываете Вы говорит о том, что на уровне схемы обе системы независимы и по команде пользователя разделяют общие ресурсы: диски, клавиатуру, монитор-экран. Это не параллелизм в исполнении кодов!
Коды на базовом и втором проце выполняются абсолютно параллельно. Например, если вы вызываете EMT для отрисовки линии, то PDP-11 проц этим почти не грузится, он лишь передаёт параметры базовому процу. Кстати, таким же полностью параллельным способом работали дисководы на Коммодорчиках - помню некоторые в 80-е чувствовали себя с ними как с многопроцессорными мейнфреймами. :)
значит основной софт допускал такое распараллеливание. В нынешних архитектурах тоже есть несколько ядер. Но старинному дос-у и windows-у их использовать для параллельных вычислений и даже для запуска разных задач в системе не удастся!
Как и писал раньше, специальный "параллельный" софт не нужен, всё работает с обычным софтом. Старинный ДОС отлично там работает - только в биос поставили соответствующие вызовы базового проца. ББС - это не многоядерная, а опционально двухпроцессорная система.
возможно ТАМ, да. тут это дикий зверь которого никто и в глаза не видел.
Их вроде дажe немножко закупали. Но в целом не реже каких-нибудь Tandy TRS-80 или даже Sinclair QL.
честно не понял, причем тут бейсик-то ???? про бейсик давно пора забыть уже наконец!
На этом бейсике когда-то АРМ сделали! Есть варианты для современных ОС, один из них называется Бренди. Если собираетесь что-то делать на ББС Микро или быстренько сделать программу под RiscOS, то этот бейсик реальная вещь. Конечно, к теме кросс-компиляция си для БК этот бейсик никакого отношения не имеет.
этот ассемблер тоже вещь в себе и как я не пытался его использовать - малоудобен. и что важно - не совместим со стандартом.
Скажите это Manwe. :)
и какой в этом смысл ?
больше игр и прочего софта для БК. :) Кстати. не заметил почти никакого интереса к играм под RT-11 для БК - https://zx-pk.ru/threads/33794-novye-igry-dlya-bk.html - хотя даже самый первый Тетрис удалось портировать. :(
одно дело, я пишу программу на ассемблере и я точно знаю размер кода и исходя из этого могу переключать странички и прочее и совсем другое дело, когда я пишу на СИ, те на _другом_уровне_абстракции_ и тут я в принципе не знаю [и что важно - не хочу знать!] когда и как переключать страницы памяти. это задача компилятора собрать код так, и переключать страницы так, чтобы это работало. c поддержкой ОС тоже самое, это тоже задача.
ну вот я беру компилятор ТУРБОСИ и собираю код под XT и почему-то там мне никто не предлагает вручную передвигать указатели сегментных регистров ;-)
На Турбо-си вам нужно указать модель памяти и иногда указывать директивы FAR/NEAR - это работает только потому что х86 умеет прямо адресовать 1 МВ, британский PDP-11 или БК могут только 64 КБ. На УКНЦ или БК0011 такого Турбо си не было и не будет. Можно будет только добиться использования оверлеев и мудрить с виртуальными масивами - второе уверен уже не намудрят, хлопот много, медленно и очень морочно. Хунта абсолютно верно указывает на то, как программные оверлеи реально делались.
для меня интерес потерян. Оно и понятно, зачем Вам ББС. :)
SuperMax
06.06.2022, 11:00
На этом бейсике когда-то АРМ сделали! Есть варианты для современных ОС, один из них называется Бренди. Если собираетесь что-то делать на ББС Микро или быстренько сделать программу под RiscOS, то этот бейсик реальная вещь. Конечно, к теме кросс-компиляция си для БК этот бейсик никакого отношения не имеет.
давайте таки про БК или как минимум про PDP-11
Скажите это Manwe. :)
говорил конечно. но он не пишет под RT11, а я пишу ибо хочу большие диски, а не образа дискет.
больше игр и прочего софта для БК. :) Кстати. не заметил почти никакого интереса к играм под RT-11 для БК - https://zx-pk.ru/threads/33794-novye-igry-dlya-bk.html - хотя даже самый первый Тетрис удалось портировать. :(
я в свое время играл, но к тому времени я быстро перешел на ДВК
На Турбо-си вам нужно указать модель памяти и иногда указывать директивы FAR/NEAR - это работает только потому что х86 умеет прямо адресовать 1 МВ, британский PDP-11 или БК могут только 64 КБ. На УКНЦ или БК0011 такого Турбо си не было и не будет. Можно будет только добиться использования оверлеев и мудрить с виртуальными масивами - второе уверен уже не намудрят, хлопот много, медленно и очень морочно. Хунта абсолютно верно указывает на то, как программные оверлеи реально делались.
не согласен про прямую адресацию, она таки костылем сделана.
Оно и понятно, зачем Вам ББС. :)
конечно - зачем в разделе про БК писать про BBC ?
уловил:
1. есть BBC к которому приделали как-то непонятно сопроцессор PDP-11 и какой тоже не ясно и как это работает тем более.
2. кто-то захотел написать компилятор СИ на PC который будет выдавать голый код без поддержки ОС или чего иного
3. компилятор будет способен выдать код который заработает на реальном PDP-11 процессоре - в БК к примеру
все верно ?
х86 умеет прямо адресовать 1 МВ
Если именнно 8086/8088 - то не умеет. Сегментные регистры - это недоперенедоДП и как и на PDP-11 - их надо трогать, если хочешь больше 64 кб. И кстати, поскольку размер "страницы" в 4 раза меньше (16 байт против 64-ёх), то и максимальный размер памяти в четыре раза меньше (мегабайт против четырёх).
говорил конечно. но он не пишет под RT11, а я пишу ибо хочу большие диски, а не образа дискет.
Пишет, у него Союз-Неон. :)
я в свое время играл, но к тому времени я быстро перешел на ДВК
На БК?! Изначальный код для Электроники на БК не идет, патчить надо. Что и сделал с помощью form.
уловил:
1. есть BBC к которому приделали как-то непонятно сопроцессор PDP-11 и какой тоже не ясно и как это работает тем более.
2. кто-то захотел написать компилятор СИ на PC который будет выдавать голый код без поддержки ОС или чего иного
3. компилятор будет способен выдать код который заработает на реальном PDP-11 процессоре - в БК к примеру
все верно ?
Почти всё, только надо чуть уточнить:
1) как работает очень даже понятно, ссылки на док были предоставлены;
2) компиляторы есть, имеют широкую известность и солидную историю. Hoglet разобрался только как это приспособить для PDP-11 и как компоновать на голое железо.
Если именнно 8086/8088 - то не умеет. Сегментные регистры - это недоперенедоДП и как и на PDP-11 - их надо трогать, если хочешь больше 64 кб. И кстати, поскольку размер "страницы" в 4 раза меньше (16 байт против 64-ёх), то и максимальный размер памяти в четыре раза меньше (мегабайт против четырёх).
Ну тогда так и 68k не умеет. :) Там сегментные регистры называются адресными. Есть, конечно, на 68к и абсолютная адресация, но её практически никогда не используют. Скажите энтузиастам 68000, что там нет прямой адресации за пределами 64 КБ и Вас пошлют на Луну или ещё подальше. :) Конечно, адресные регистры погибче, чем сегментные, но они и место в опкоде занимают, а сегментные нет - это действительно недоделанная часть ДП.
Базу практическти всегда на любых процах надо указывать, если адресуем больше 64 КБ. У х86 только этих базовых регистров мало. Но кругом свои "плюшки", на Арме или даже дорогущих мейнфреймах баз надо много, так как адресуют там смещения только по 4 кб. Но в большинстве архитектур регистры универсальные и это некоторое преимущество над х86 и 68к.
Ну тогда так и 68k не умеет
Понятия не имею, что он умеет или не умеет. Я сказал именно про 8086/8088, а кто и что там у себя в гоолове за меня додумывает - это иховые проблемы
> Ну тогда так и 68k не умеет. Там сегментные регистры называются адресными.
Это - бред. Адресные регистры в m68k - 32-х разрядные, и смещение тоже 32-х разрядное, так что всегда есть полный доступ ко всей памяти без лишних манипуляций. А в 8086 - 16бит сегмент - 16 бит смещение. Соответственно, m68k - 32х разрядный процессор, а 8086 - 16-и.
Это - бред.
У ТС - своё видение в голове, как правило "не совпадающее с мнением редакции" :)
- - - Добавлено - - -
а 8086 - 16-и.
Ну, адрес снаружи у него 20-ти битный, но внутри всё равно напрямую (командами) он с ним работать не умеет, так что - да, 16-ти битный с недоДП. Сильно недоДП по сравнениею с PDP-11 :)
Это - бред. Адресные регистры в m68k - 32-х разрядные, и смещение тоже 32-х разрядное, так что всегда есть полный доступ ко всей памяти без лишних манипуляций. А в 8086 - 16бит сегмент - 16 бит смещение. Соответственно, m68k - 32х разрядный процессор, а 8086 - 16-и.
Надо лучше знать матчасть! У 68000 смещение 16-бит, на одну базу более 64 КБ - никак. И не слушайте Хунту, он от чего-то всегда страдает. :)
У 68000 смещение 16-бит
А у PDP-11 смещение в командах перехода типа BR, BEQ, BNE, и т.п. вообще восьмибитное, так что перед нами - вообще 8-битный по адресу компа, аха.
Надо лучше знать матчасть!
Легка ноша чушь несущего, мне минуты чтения в google хватило понять, что ТС, как обычно, имеет своё видение в голове.
- - - Добавлено - - -
И не слушайте Хунту
Уже начинаем указывать - что и кому делать? Ну ну.
А у PDP-11 смещение в командах перехода типа BR, BEQ, BNE, и т.п. вообще восьмибитное
Ну это все же укороченные команды перехода. У Z80 в таких командах тоже 8 бит, но в "нормальных"-то 16, на всю шину адреса.
Ну это все же укороченные команды перехода.
Я это знаю. Так же как и понимаю то, что это не имеет никакого отношения к прямой адресации памяти в пределах внешней шины, внутренняя шина имеет меньше разрядов.
Я даже понял, причём здесь 16-ти битное смещение на 68K и теперь могу сказать, что в нём для полной адресации памяти никаких костылей не требуется.
Но, как я сказал, у ТС своё болото в голове и уверять его в чём либо - только это болото месить.
Я даже понял, причём здесь 16-ти битное смещение на 68K и теперь могу сказать, что в нём для полной адресации памяти никаких костылей не требуется.
А может стоит попробовать без деклараций, а просто взять и сравнить?
Рассмотрим код для 8088
mov ds,ax
mov bx,[1000]
Сравним его с аналогичным кодом для 68000
move d1,a1
move 1000(a1),d2
И где в первом случае больше "костыльности"? Проблема х86, как и писал выше, только в том, что сегментных регистров всего 4, а в 68000 - 7. Ну и, конечно, у 68000 нет проблем с большими массивами.
Как обычно - читаем только отдельные буквы.
для полной адресации памяти
Ну-ка, пример кода для 8086/8088 без использования сегментных регистров весь мегабайт памяти проадресуйте?
Сравним его с аналогичным кодом для 68000
Нихрена он не аналогичный.
В первом случае недоДП (аналог в PDP-11 - MOV #1000, @#172344 ; MOV #40000, R0)
Во втором случае - использование для смещения от базы (аналог в PDP-11 MOV #2, R0 ; MOV 1000(R0), R1)
То есть ТС даже матчасть нихрена не знает
Ну и поскольку ТС в который раз показал своё болото - дальше не интересно общаться на эту тему.
Пойду дальше исходник монитора XXDP восстанавливатью
HardWareMan
12.06.2022, 07:46
Проблема х86, как и писал выше, только в том, что сегментных регистров всего 4, а в 68000 - 7. Ну и, конечно, у 68000 нет проблем с большими массивами.
1. Не 7 а 8. Никто не запрещает использовать A7 не только как SP.
2. У М68К адресные регистры это не сегменты. Это полноценные адресные регистры на полную адресацию, причем с байтовой точностью. Это в отличии от настоящих сегментных регистров у 8088. Ну и использовать их как временное быстрое хранилище (в виду ограниченности работы ALU с ними) тоже сильное и полезное отличие от всё тех же настоящих сегментных регистров.
Нихрена он не аналогичный.
Хунта получает очередную двойку за абсолютное незнание предметной области - коды функционально абсолютно аналогичны. :)
В первом случае недоДП (аналог в PDP-11 - MOV #1000, @#172344 ; MOV #40000, R0)
Во втором случае - использование для смещения от базы (аналог в PDP-11 MOV #2, R0 ; MOV 1000(R0), R1)
И как во втором случае адресовать больше 64 КБ? К сожалению, Хунта, вам опять двойка. :)
1. Не 7 а 8. Никто не запрещает использовать A7 не только как SP.
2. У М68К адресные регистры это не сегменты. Это полноценные адресные регистры на полную адресацию, причем с байтовой точностью. Это в отличии от настоящих сегментных регистров у 8088. Ну и использовать их как временное быстрое хранилище (в виду ограниченности работы ALU с ними) тоже сильное и полезное отличие от всё тех же настоящих сегментных регистров.
Почти согласен с Вами, но сегментные регистры в 8088 играют роль адресных - тут просто разная терминология. Понятно что их разрабатывали в разных парадигмах, но получилось что-то практически одно и тоже, мой пример это подтверждает. Можно ещё добавить, что если бы у х86 было больше сегментных регистров, их было бы также можно использовать как быстрое временное хранилище. Хотя ES иногда в этой роли и используют. И ещё, если регистр используется для хранения базы, то байтовая точность - это мелочь, типа до 15 байт иногда экономить на выравнивании.
HardWareMan
12.06.2022, 09:08
Почти согласен с Вами, но сегментные регистры в 8088 играют роль адресных - тут просто разная терминология. Понятно что их разрабатывали в разных парадигмах, но получилось что-то практически одно и тоже, мой пример это подтверждает. Можно ещё добавить, что если бы у х86 было больше сегментных регистров, их было бы также можно использовать как быстрое временное хранилище. Хотя ES иногда в этой роли и используют.
Если не привязываться к 8086 и 80286, то расширенные сегментные регистры (ECS/EDS и так далее) уже ближе к An у М68К, но есть нюанс. В любом случае, конкретно здесь идёт речь в рамках 8086/8088 (в зависимости от ширины внешней шины), а у них сегментные регистры только 16 бит, что на 4 бита меньше реального адресного пространства, это раз. Сегментные регистры не могут указывать на элемент памяти в цикле, для этого нужен дополнительный регистр (например ES:DI/DS:SI), в то же время как An у M68K самодостаточный указатель, который имеет предекремент, постинкремент и прочие плюшки, необходимые для доступа данных к массивам в циклах.
PS Единственное оправдание сегментных регистров это переносимость программ в адресном пространстве. Точнее, они именно для этого и делались.
коды функционально абсолютно аналогичны
Нет. Кол.
И как во втором случае адресовать больше 64 КБ?
То есть сравнение полноценного 32-битного процессора и 16-ти битного? Второй кол.
Если не привязываться к 8086 и 80286, то расширенные сегментные регистры (ECS/EDS и так далее) уже ближе к An у М68К, но есть нюанс. В любом случае, конкретно здесь идёт речь в рамках 8086/8088 (в зависимости от ширины внешней шины), а у них сегментные регистры только 16 бит, что на 4 бита меньше реального адресного пространства, это раз. Сегментные регистры не могут указывать на элемент памяти в цикле, для этого нужен дополнительный регистр (например ES:DI/DS:SI), в то же время как An у M68K самодостаточный указатель, который имеет предекремент, постинкремент и прочие плюшки, необходимые для доступа данных к массивам в циклах.
PS Единственное оправдание сегментных регистров это переносимость программ в адресном пространстве. Точнее, они именно для этого и делались.
расширенные сегментные регистры (ECS/EDS и так далее)?! Это из какой сказки? :) И как там уже писали, сегментные регистры на 8088/86 - 20-битные, у которых младшие 4 бита всегда нули. А во остальном Вы правы, адресные регистры более гибкие. чем сегментные, но об этом тоже писал.
SuperMax
12.06.2022, 11:49
давайте таки вернемся к PDP-11 ?
Перенесите уже тему во Флейм, а то к БК эти разговоры не имеют никакого отношения.
Перенесите уже тему во Флейм, а то к БК эти разговоры не имеют никакого отношения.
Дело хозяйское, но тема именно про компиляцию программ на си для БК. А что некоторые перевозбудились про х86 - это вроде претензии к соответствующим персоналиям надо предъявлять.
shattered
12.06.2022, 21:49
давайте таки вернемся к PDP-11 ?
назад в 1970 год?
HardWareMan
13.06.2022, 12:05
расширенные сегментные регистры (ECS/EDS и так далее)?! Это из какой сказки? :)
Из той самой, что изначально в #17 сообщении указывался именно 8086/8088. О каких расширенных регистрах идёт речь, если они появились только в 80386?
И как там уже писали, сегментные регистры на 8088/86 - 20-битные, у которых младшие 4 бита всегда нули. А во остальном Вы правы, адресные регистры более гибкие. чем сегментные, но об этом тоже писал.
1. Если биты недоступны программисту, значит технически их нет.
2. Все доступные документы говорят, что сегментные регистры у 8086/8088 16 бит. Откуда информация, что они полноценно 20ти битные с обнулёнными младшими битами? На основе декапа? Можете предоставить ссылку? Ну и если адрес там формируется как SEG:OFS с частичным перекрытием, которое организуется функцией прямого сложения, то младшие биты 20ти битного регистра бы мешали, так как постоянно приходилось бы их обнулять. Я скорее поверю, что они просто захардкожены в 0 на 20ти битном сумматоре адреса (младшие 4 для сегмента и старшие 4 для смещения). И это прямо означает, что они не существуют как часть регистров.
Из той самой, что изначально в #17 сообщении указывался именно 8086/8088. О каких расширенных регистрах идёт речь, если они появились только в 80386?
Как всё плохо! Неужели некому поправить человека?! Ну нету на х86 расширенных сегментных регистров! Ни на 8088, ни на 80386, ни даже на 80786. :)
HardWareMan
29.06.2022, 10:47
Как всё плохо! Неужели некому поправить человека?! Ну нету на х86 расширенных сегментных регистров! Ни на 8088, ни на 80386, ни даже на 80786. :)
Ого, человек 13 дней (2 недели!) не мог прийти в себя от такой чудовищной ошибки, которую допустил кто-то в интернете, чтобы написать об этом сразу. Ну как ты там, уже, я вижу, успокоился? Ну вылетело из головы, что у x86 сегменты так и остались 16 бит а у x64 они вообще не работают. Мне можно, у меня в башке куча архитектур загружено на данным момент, допустимы утечки знаний из одной в другую.
SuperMax
29.06.2022, 19:35
или мы возвращаемся к PDP-11 и в частности БК или тема едет во флейм
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot