Как я могу получить доступ к полному пространству памяти во FreeDOS с помощью приложения C - PullRequest
0 голосов
/ 10 мая 2019

У меня есть встроенное приложение, написанное на C, работающее на FreeDOS на процессоре в стиле 486 / 386DX (http://www.dmp.com.tw/tech/vortex86dx). Компьютер имеет 256 МБ памяти, но у меня, похоже, нет доступа к большинству из него.

Я написал простую программу для исследования (вызывает malloc() в цикле, пока не будет возвращен нулевой указатель), и хотя размер каждого запроса malloc() слегка влияет на результат, он всегда находится в пределах 300 КБ. Мой код должен отображать блоки 16-битной памяти, поскольку моя реализация malloc(), кажется, принимает только аргумент unsigned short. Не страшно, так как мне нужно всего 3 МБ или около того, примерно 50 блоков (это кольцевой буфер для сбора данных, поэтому такой обходной подход не так уж и громоздок). Так как я получаю гораздо больше памяти, чем 16 бит (300 КБ против 64 КБ), я знаю, что это не совсем 16-битная проблема. Я предполагаю, что это связано с пределом в 640 КБ, о котором я читал в своем исследовании, но я не понимаю, является ли это проблемой компилятора или ОС.

Я использую компилятор Borland BC5 и пробовал все виды настроек модели памяти и параметров компилятора, которые оказали минимальное влияние на результаты. В настоящее время я изучаю HIMEMX.EXE и JEMM386.EXE, но так как я до сих пор выкал много неправильных деревьев, подумал, что это стоит вопроса в то же время. Я также начал изучать Linux, хотя это серьезное изменение, поскольку код очень специфичен для DOS, и у меня нет опыта работы с Linux.

Я надеюсь, что есть только некоторые настройки или команды, которые мне нужны, чтобы не использовать огромный порт и ОС, с которыми я не знаком. Моя установка DOS в настоящее время состоит только из копирования файлов config.sys и sys.com на жесткий диск, поэтому у меня нет доступа к исполняемым файлам расширенной памяти, описанным выше, для экспериментов. Предположение, что это только приведет меня к следующей трудности, так что, надеюсь, кто-то с опытом работы в этом древнем отделе сможет протянуть руку, пока у меня не будет больше времени, чтобы ознакомиться с современными инструментами.

Так стоит ли мне больше интересоваться настройками ОС или настройками компилятора (или самого компилятора)?

Ответы [ 2 ]

2 голосов
/ 11 мая 2019

В частности, относительно malloc(), насколько я помню, реализация Borland принимает аргумент размера 16 бит.Библиотека Borland имеет «огромную» модель памяти версии halloc() (и соответствующий ей hfree()), которая может выделять большие блоки (больше 64 КБ).

JEMM386 это менеджер расширенной памяти , при котором объем памяти превышает 1 МБ в область «высокой памяти» выше 640 КБ - размер этой области составляет всего 384 КБ, и не все из них доступны для подкачки памяти, что, вероятно, является причиной наблюдаемого вами ограничения в 300 КБ.экспериментом.

Для полного использования ресурсов памяти для кода и данных необходимо использовать DPMI (интерфейс защищенного режима DOS).Программа DPMI - это настоящая программа в 32-битном защищенном режиме с механизмом доступа к API DOS (именно так работала Windows 3.x до того, как Windows 95 стала операционной системой сама по себе, а не в графической среде над DOS).

Программы DPMI запускают процессор в защищенном режиме, а не real .Это немного усложняется тем, что есть два защищенных режима;16-битный защищенный режим 80286 (DPMI16) и 32-битный защищенный режим 80386 (DPMI32).В вашем случае вам нужно иметь дело только с DPMI32.

Для компилятора Borland DPMI поддерживался с помощью инструментов DOS Power Pack .Однако Power Pack был разработан для работы с Borland C ++ 4.02 и 4.5x, а не 5.0. В этом техническом примечании объясняется, как можно использовать Power Pack с BC ++ 5, но не рекомендуется.В нем говорится, что он работает только с инструментами командной строки, а не с IDE.Тем не менее, это другое техническое примечание затем объясняет, как заставить его работать в IDE, но объясняет, что BC ++ 5 RTL не будет работать.В целом, это не похоже на приятный опыт.

Однако нет необходимости вообще задумываться о переходе на Linux - вам просто нужно использовать набор инструментов, который поддерживает DPMI32 и позволяет вам строить свой код как истинный.битовый код в среде DOS.

Подходящие цепочки инструментов могут включать в себя:

Все вышеперечисленное, кроме DJGPP, требует сторонних DOS-удлинителей (хосты DPMI), некоторые из которых перечислены в списке здесь . DJGPP включает в себя расширитель (как описано здесь ), поэтому может быть самым простым выбором, если не самым современным (но не Borland). Обратитесь к документации по инструментальной цепочке, чтобы определить, чтопроблема с теми, которые используют сторонние экстендеры в том, что в то время какКомпилятор может оставаться доступным, расширитель может исчезнуть (как в случае с Digital Mars).

1 голос
/ 10 мая 2019

Старый добрый DOS был настроен на использование 640 КБ памяти, а адресное пространство увеличилось только до 1 МБ.

Более новые методы включают "нереальный режим" (о котором я только что слышал в первый раз, но мне это кажется логичным).

Но во времена DOS вам приходилось использовать EMS и / или XMS.

Это были методы доступа к памяти за пределами окна используемой памяти.

EMS имела окна памяти, в которые можно было отображать страницы этой дополнительной памяти.

В XMS у вас была специальная функция, которая помогала вам копировать данные из памяти и в память, используя определенный адрес функции.

...