Кросс-компиляция для програм на си

[litwr]

тогда биос/монитор тоже надо переписывать под 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 (биос фактически) учитывает наличие второго процессора и работает прозрачно для прикладных программ. Конечно, если прикладная программа будет работать не через системные вызовы, а прямым использованием аппаратуры, то она на втором процессоре не заработает - у каждого процессора память отдельная.

[andrews]

Дело в том, что СР/М для BBC Micro существуют в двух вариантах с первой половины 80-х.

Я не об этом. А о том, чтобы запустить на 65с02 исполняемый код[CP/M для z80 причем конкретного железа под него!] Конечно он эти коды должен воспринимать как данные для пересылки на параллельный процессор.
То есть у нас есть живой BBC микро, а вот того конкретного железа нет и в помине! И нет пзу его биоса/монитора-программы.
Ведь монитор-экран есть и клавиатура, и диски, но всё другое! Поэтому тот код, даже если "воткнуть" параллельно железный z80 правильно исполнятся не будет! А придется основному 65с02 перехватывать такие "железо-зависимые коды" и преобразовывать в свои собственные, чтобы пользователь мог видеть правильный результат на экране, а нажатие клавиш попадало в нужные яп параллельного процессора.
Об эмуляторах и говорить нечего! Если в него такую функцию специально не заложить.
То, что описываете Вы говорит о том, что на уровне схемы обе системы независимы и по команде пользователя разделяют общие ресурсы: диски, клавиатуру, монитор-экран. Это не параллелизм в исполнении кодов!

Но в реальности люди просто преобретали второй 6502 процессор и автоматически получали хороший разгон - это легко проверить на эмуляторах

значит основной софт допускал такое распараллеливание. В нынешних архитектурах тоже есть несколько ядер. Но старинному дос-у и windows-у их использовать для параллельных вычислений и даже для запуска разных задач в системе не удастся!

[SuperMax]

Документации немного, все-таки это поздний хоббистский проект. Вот несколько ссылок
Почему экзотичность? ВВС М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 КБ, ДП нет.

для меня интерес потерян.

[Hunta]

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

когда я пишу на СИ, те на _другом_уровне_абстракции_ и тут я в принципе не знаю

Учитывая, что и на ассемблере (чаще всего) и на С (практически наверняка) будут подключаться всякие дополнительные модули и библиотеки, на этапе компиляции компилятору не будет известно - чего и сколько, а соотвественно - как переключать страицы ДП. Это може знать только линкер и менно он (и в RT и в RSX) умеет создавать оверлеи, резидентные в памяти. Если хочется делать это на этапе компиляции - придётся это делать руками.

[litwr]

Я не об этом. А о том, чтобы запустить на 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]

На этом бейсике когда-то АРМ сделали! Есть варианты для современных ОС, один из них называется Бренди. Если собираетесь что-то делать на ББС Микро или быстренько сделать программу под 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 процессоре - в БК к примеру

все верно ?

[Advertiser]

[Hunta]

х86 умеет прямо адресовать 1 МВ

Если именнно 8086/8088 - то не умеет. Сегментные регистры - это недоперенедоДП и как и на PDP-11 - их надо трогать, если хочешь больше 64 кб. И кстати, поскольку размер "страницы" в 4 раза меньше (16 байт против 64-ёх), то и максимальный размер памяти в четыре раза меньше (мегабайт против четырёх).

[litwr]

говорил конечно. но он не пишет под 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к.

[Hunta]

Ну тогда так и 68k не умеет

Понятия не имею, что он умеет или не умеет. Я сказал именно про 8086/8088, а кто и что там у себя в гоолове за меня додумывает - это иховые проблемы

[haywire]

> Ну тогда так и 68k не умеет. Там сегментные регистры называются адресными.

Это - бред. Адресные регистры в m68k - 32-х разрядные, и смещение тоже 32-х разрядное, так что всегда есть полный доступ ко всей памяти без лишних манипуляций. А в 8086 - 16бит сегмент - 16 бит смещение. Соответственно, m68k - 32х разрядный процессор, а 8086 - 16-и.