слушайте, друзья, а вот скажите мне, кто-то из вас использует что-то из всего здесь упомянутого где-то в работе... Есть в стране вообще работа для таких специалистов?
слушайте, друзья, а вот скажите мне, кто-то из вас использует что-то из всего здесь упомянутого где-то в работе... Есть в стране вообще работа для таких специалистов?
Пару десятилеток назад я как системщик с парой студентов и парой прикладников сделал проект для одного крупного банка страны на С+OracleEmbSQL (3 платформы: DEC VAX C, AIX VACPP, Win MS Vstudio CPP) который продался за 150К$ (правда проработал он очень не долго - у них случилась реорганизация и вышестоящей организации по принципу "сделано не нами" всё это не понадобилось). Студентов пришлось научить всему, начиная от использования экранного дебагера заканчивая логикой программ - ну там очереди, треды, IPC, ловушки и т.п. Там было несколько миллионов строк кода (самописного из них порядка 10% - собственно сервера 3-звенки, платформенно-зависимые вещи, GUI на curses {мой труд в-основном, и студентов} остальное полученное source-level транслятором с DEC VAX C и Oracle RDB {прикладниками} на целевые платформы). Позже С пользовался только для души, а вообще больше люблю Паскаль (именно Борландовские компиляторы). И вообще я не программист (просто любую тему как ту временную начинаю с максимального расширения кругозора в теме перед тем как начинать зарываться вглубь), тем паче мне странно видеть какое тут иной раз задвигают программеры которые некоторые узкие вещи наверняка знают гораздо лучше меня, но надо же и вширь думать тоже.Сообщение от Знахарь
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Имеешь в виду Си для Z80?
Я - коммерческий Оберон-программист. Мне за это платят деньги. И это интересная работа, творческая.
Как применять в коммерции Си для Z80 в наше время - я ответить затрудняюсь. Сейчас все ринулись на ARM'ы, в основном.
Просто добавьте сюда:
В z88dk есть два компилятора c. Один из них - sccz80, который не является оптимизирующим компилятором и совместим с C89 с некоторыми расширениями. Он также примет некоторые K & R C. Другим компилятором является zsdcc, который является вилкой sdcc-z80. zsdcc C89 совместим с расширениями на C99 и C11. zsdcc является оптимизирующим компилятором, был изменен из родительского sdcc, создает лучший код, чем сам sdcc, и исправил многие проблемы генерации кода, которые были в sdcc. sdcc устраняет многие из этих ошибок, а также за последние 6 месяцев.
О том, насколько хорошо поддерживается z80 в рамках проекта sdcc, он уделяет большое внимание. Один из основных разработчиков sdcc (Philip) интересуется z80. Он очень чувствителен ко всем вопросам, которые мы поднимаем, и даже решил модифицировать генератор кода z80, чтобы настроить новые инструкции в zx next, который является очень нишевым.
Три соглашения вызова, которые поддерживают zsdcc, sdcc и sccz80, являются стандартными c, z88dk_callee и z88dk_fastcall. Соглашения z88dk_callee и z88dk_fastcall были добавлены в sdcc для z88dk, потому что z88dk имеет очень большую библиотеку ассемблера (> 1000 функций), которая использует z88dk_callee и z88dk_fastcall для эффективного вызова функций языка ассемблера. Добавление позволило нам включить часть компилятора s sdcc в z88dk.
Хотя z88dk_callee и z88dk_fastcall предназначены для взаимодействия с функциями языка ассемблера, оба zsdcc и sccz80 могут генерировать код для связи z88dk_fastcall.
Стандартная привязка c дает ответчику ответственность за очистку параметров, переданных в стек. Последовательность вызовов: нажмите параметры в стеке, вызовите функцию и вытащите параметры из стека. Эта привязка должна использоваться для функций vararg, таких как printf и для указателей функций.
Связь z88dk_fastcall имеет один параметр, передаваемый через регистр в подмножестве DEHL. Параметр может быть длиной 8, 16 или 32 бит.
Связь z88dk_callee несет ответственность за очистку стека от вызываемой функции. Таким образом, последовательность вызовов: нажмите параметры в стеке и вызовите функцию. Вызываемая функция реализована в ассемблере, и она просто добавит параметры в регистры, которые очистят стек одновременно.
Как fastcall, так и callle linkage ускоряют программы и уменьшают размер программы на большое количество. Заголовки в z88dk гарантируют, что привязка и связь fastcall всегда выбираются, когда это возможно. Нет проблем с нажатием одного байта или двух или четырех параметров.
Что касается того, почему больше параметров не передается через регистр, нет смысла делать это, если первое, что нужно сделать компилятору, - это нажать их на стек из-за давления в регистре. В архитектуре z80 нет бесконечного количества регистров. Для функций языка ассемблера это может быть полезно, но вам нужно помнить, что вызывающему абоненту необходимо собрать эти параметры в регистрах перед выполнением вызова. По мере того, как больше значений помещаются в регистры перед вызовом, у компилятора больше трудностей возникает сбор дополнительных параметров в остальных регистрах. Возможно, придется прибегать к нажатию параметров на стек, а затем выталкивать их перед вызовом, который не лучше, чем привязка. Олег предположил, что несколько параметров одного байта могут быть легко собраны в регистрах перед вызовами, и это может быть так.
Есть некоторая путаница в связи с вызовами функций. Для этого нет никаких стандартов, кроме некоторых конкретных операционных систем / процессоров, может быть определена ABI, которая стандартизирует привязку для определенных платформ. Взаимодействие в противном случае зависит от компилятора. «register» не является ключевым словом для определения связи вызова функции. Он предназначен как подсказка для компилятора, когда автоматические переменные, объявленные внутри функции, лучше всего помещать в регистр, а не в стек. В стандарте C ничего не говорится о связи вызова функций и о том, что вы видели как «cdecl», а также привязка pascal не являются стандартными, но имеют вес, потому что Microsoft или другие доминирующие компиляторы используют его. Вы можете просмотреть https://en.wikipedia.org/wiki/X86_calling_conventions список перечней популярных ссылок вызовов функций для архитектуры архитектуры x86.
Ни sdcc, ни sccz80 не позволяют передавать структуры по значению. Это рассматривается как низкий приоритет, потому что очень неэффективно передавать структуры по значению, и вместо этого они скорее должны быть переданы указателем. Передача структуры по значению означает использование ldir для копирования исходной структуры в память, зарезервированную в стеке внутри целевой функции. Чтобы вернуть структуру, функция должна использовать ldir для копирования локальной структуры в память, ожидающей в памяти памяти вызывающего. Это не очень эффективно. Однако sdcc / zsdcc делают это внутренне для 64-битных длинных целых чисел в списках параметров и в возвращаемых значениях. В z88dk мы потратили некоторое усилие, сохранив размер кода для этих случаев.
2134/5000
О printf и scanf, библиотека sdcc предназначена для кросс-платформенности (работает на всех целевых процессорах) и предназначена для таргетинга на встроенные системы, которые считаются «необоснованными», что означает отсутствие базовой операционной системы. В большинстве случаев это означает, что scanf (и sdcc не имеет scanf) мало нуждается, и printf просто переходит к одной процедуре putchar, не имеющей понятия рулевого вывода для разных ФАЙЛОВ. Кросс-платформенное требование для sdcc также означает, что его библиотека должна оставаться почти полностью написанной на C, что является большим недостатком по сравнению с, скажем, z88dk, iar и даже hitech cpm.
Однако z88dk не имеет таких требований, и его библиотека полностью написана в asm, включая printf и scanf, которая проходит через FILE * и устройства, созданные на файловых дескрипторах, следующих за моделью unix. Stdio также объектно ориентирован, поэтому вы можете подклассировать драйверы, чтобы изменить их поведение.
Реализация asm printf поддерживает эти конвертеры, включая все параметры форматирования, указанные в стандарте:
% d,% u,% x,% X,% o,% n,% i,% p,% B (двоичный),% s,% c,% I (интернет IPv4),% ld,% lu,% lx,% lX,% lo,% ln,% li,% lp,% lB,% lld,% llu,% llx,% llX,% llo,% lli,% a,% A,% e,% E, % f,% F,% g,% G
Список аналогичен для scanf. Как вы можете видеть, там есть float, а также 64-битные целые числа.
Пользователь контролирует, сколько из этих конвертеров включено в программу во время компиляции. Если вы хотите только% s, вы можете так сказать.
Hitech C (cpm или msdos) редко производит быстрый или малый код, чем z88dk / zsdcc, и я бы никогда не говорил в контексте большой программы из моего опыта в компиляции некоторых больших тестовых программ для сравнения. Есть одно исключение: hitech c, похоже, имеет очень быструю поплавковую реализацию. К сожалению, это также ненадежно, так как оно часто имеет большие ошибки и иногда неправильные результаты для трансцендентных функций.
Для спектра в частности, около 50 игр были написаны с использованием z88dk в C, и многие из них довольно велики. Мы достаточно уверены, что самые важные ошибки были устранены. Избавление от них - всегда постоянный процесс.
original in english:
Скрытый текст
Just to add here:
Within z88dk there are two c compilers. One is sccz80 which is not an optimizing compiler and is C89 compliant with some extensions. It will accept some K&R C as well. The other compiler is zsdcc which is a fork of sdcc-z80. zsdcc is C89 compliant with extensions into C99 and C11. zsdcc is an optimizing compiler, has been modified from the parent sdcc, produces better code than sdcc itself and has fixed a lot of the code-generation issues that were in sdcc. sdcc has been eliminating a lot of those bugs as well in the past 6 months.
About how well supported the z80 is within the sdcc project, it sees a great deal of attention. One of the main sdcc developers (Philip) has an interest in the z80. He is very responsive to all issues we raise and has even committed to modifying the z80 code generator to target the new instructions in the zx next, which is a very niche machine.
The three calling conventions that zsdcc, sdcc and sccz80 support are standard c, z88dk_callee and z88dk_fastcall. The z88dk_callee and z88dk_fastcall conventions were added to sdcc for z88dk because z88dk has a very large assembly language library (> 1000 functions) that uses z88dk_callee and z88dk_fastcall to efficiently call assembly language functions. The addition allowed us to incorporate the c compiler portion of sdcc into z88dk.
Although z88dk_callee and z88dk_fastcall are intended for interfacing to assembly language functions, both zsdcc and sccz80 can generate code for z88dk_fastcall linkage.
The standard c linkage gives the caller responsibility for clearing parameters passed on the stack. The call sequence is: push parameters on the stack, call the function and pop the parameters off the stack. This linkage must be used for vararg functions like printf and for function pointers.
The z88dk_fastcall linkage has one parameter passed via register in a subset of DEHL. The parameter can be 8, 16 or 32 bits long.
The z88dk_callee linkage gives responsibility for cleaning up the stack to the called function. So the call sequence is: push parameters on the stack and call the function. The called function is implemented in assembler and it will simply pop the parameters into registers which will clear the stack at the same time.
Both fastcall and callee linkage speed up programs and reduce program size by a large amount. The headers in z88dk ensure that callee and fastcall linkage are always selected when possible. There are no problems with pushing one byte or two or four for parameters.
As for why more parameters don't get passed via register, there's no point in doing that if the first thing the compiler needs to do is push them on the stack because of register pressure. There is not an infinite supply of registers available in the z80 architecture. For assembly language functions there may be a use for it but you do have to keep in mind the caller needs to gather those parameters into registers before making the call. As more values are placed in registers before the call, the compiler has more difficulty gathering further parameters into the remaining registers. It may have to resort to pushing params onto the stack and then popping them before the call which is no better than callee linkage. Oleg has suggested that multiple single byte parameters could easily be gathered in registers before calls and that may be the case.
There's some confusion about function call linkage. There is no standard for this except for some specific operating systems / processors there may be an ABI defined that standardizes linkage for specific platforms. The linkage is otherwise up to the compiler. "register" is not a keyword for defining function call linkage. It's intended as a hint to the compiler when automatic variables declared inside a function would best be placed in a register rather than in the stack. The C standard says nothing about function call linkage and things you've seen like "cdecl" and pascal linkage are non-standard too but have weight because Microsoft or other dominant compilers use it. You can see https://en.wikipedia.org/wiki/X86_calling_conventions for a list of some popular function call linkages for the x86 architecure.
Neither sdcc nor sccz80 allows structures to be passed by value. This is seen as a low priority because it's very inefficient to pass structs by value and these should rather be passed by pointer instead. Passing a struct by value means using ldir to copy the source struct into memory reserved on the stack inside the target function. To return a struct, the function must use ldir to copy the local struct to memory waiting in the caller's memory space. This is not very efficient. However, sdcc/zsdcc are doing this internally for 64-bit long long integers in parameter lists and in return values. In z88dk we spent some effort keeping the code size down for these cases.
About printf and scanf, sdcc's library is meant to be cross platform (working on all processors it targets) and is meant to target embedded systems which are considered "unhosted" meaning there is no underlying operating system. In most situations this means there is little need for scanf (and sdcc does not have scanf) and printf simply goes to a single putchar routine with no concept of steering output to different FILEs. The cross-platform requirement for sdcc also means its library must remain written almost entirely in C which is a large disadvantage compared to, say, z88dk, iar, and even hitech cpm.
However, z88dk has no such requirements and its library is written entirely in asm, including printf and scanf which passes through FILE* and devices instantiated on file descriptors following the unix model. Stdio is also object oriented so you can subclass drivers to change their behaviour.
The asm printf implementation supports these converters including all the formatting options specified in the standard:
%d, %u, %x, %X, %o, %n, %i, %p, %B (binary), %s, %c, %I (internet IPv4), %ld, %lu, %lx, %lX, %lo, %ln, %li, %lp, %lB, %lld, %llu, %llx, %llX, %llo, %lli, %a, %A, %e, %E, %f, %F, %g, %G
The list is similarly comprehensive for scanf. As you can see there is float in there as well as 64-bit integers.
The user has control over how many of these converters are included in the program at compile time. If you only want %s you can say so.
Hitech C (cpm or msdos) rarely produces faster or small code than z88dk/zsdcc and I would say never in the context of a large program from my experience in compiling some large test programs for comparison. There is one exception: hitech c seems to have a very fast float implementation. Unfortunately it's also unreliable since it quite often has large errors and sometimes wrong results for transcendental functions.
For the spectrum specifically, around 50 games have been written using z88dk in C and many are quite large. We're fairly confident that the most important bugs have been eliminated. Getting rid of them all is always an ongoing process.
[свернуть]
В контексте больших программ - назрел вопрос. Когда код раздувается сильно, настаёт время задуматься о том, куда и как его перемещать. Поскольку можно включить в 0е окно проца ещё какую-то страницу, то хотелось бы туда скинуть часть сишного кода. Т.е. допустим, часть функций сидит в адресах 0x8000..., часть кода в 0x0000. На стадии загрузчика я бы мог скинуть этот код туда, в 0. Например, на старом асме M80 была такая директива .phase и .dephase, в ужасме есть аналогичная директива, благодаря которой код указанный внутри директивы собирается на указанный директивой адрес. соответственно, загрузчик этот код скидывает на нужный адрес. Если делать через org, то в бинарном файле дует овердофига нулей. Какие есть вариант при помощи sdcc разогнать части кода по памяти по разным, каким мне надо адресам?
1. Блобы и при старте раскидывать по адресам?
2. Линковать разные модули в разные бинарники с разных адресов?
3. .... ?
.phase и .dephase не подходят для этого. .фаза - это изменение адреса сборки и сохранение собранного результата по другому адресу памяти. При запуске CPU перед запуском копирует раздел .phase на правильный адрес назначения. Тогда в памяти есть две копии.
z88dk имеет это тоже, и он наиболее часто используется в бездисковых системах без дисков, чтобы скопировать некоторые исполняемые файлы в оперативную память перед тем, как выложить ром и начать. Здесь приведен пример такой системы: https://github.com/RC2014Z80/RC2014/.../cpm22.asm#L69, где cpm 2.2 хранится в ROM-изображении, которое копируется в ram после включения питания. Человек, делающий это, упустил трюк, потому что было бы лучше сохранить изображение cpm в сжатой форме.
sdcc сама определяет карту памяти, используя области. Это уже цитировалось в нескольких местах, но я думаю, что это плохо понимается. областям дается org, чтобы определить, где они находятся в пространстве памяти. Вы можете определить несколько областей с тем же или перекрывающимся диапазоном адресов, чтобы покрыть пространство памяти> 64k. Выходной файл sdcc является файлом hex hex, который генерирует представление этого пространства памяти в компактном виде (т.е. без заполнения нуля). Вы можете использовать стандартные инструменты, чтобы превратить это в несколько двоичных файлов.
Инструменты z88dk более продвинутые. Внутри он имеет представление любого пространства памяти, которое может быть определено индивидуально для каждой цели. Вывод обрабатывается через отдельную программу «appmake», которая может превратить это представление в подходящий вывод, будь то ленточный образ, исходные двоичные файлы, шестнадцатеричный ключ, моментальные снимки, образы дисков и т. Д. Но центральным для этого является СЕКЦИЯ, которая функционально такая же, как и область Sdcc.
Чтобы увидеть, как это делается, вот краткий пример для zx next. Zx next имеет несколько пространств памяти, но наиболее важным является организация ram на 224 страницы по 8 k каждый. Каждая из этих страниц может быть помещена в любой диапазон 8k в 64-килограммовом пространстве z80. Я не хочу вдаваться в подробности здесь, но для понимания этого примера должно быть достаточно информации.
В asm я поместил некоторые вещи на некоторые 8k-страницы:
Скрытый текст
.phase and .dephase are not the right tool for this. .phase is for changing the assemble address and storing the assembled result at another memory address. At startup, the cpu copies the .phase section to the correct destination address before starting. Then there are two copies in memory.
z88dk has this too and it is most frequently used in rom-only diskless systems to copy some executable into ram before paging out the rom and starting. There is an example of such a system here: https://github.com/RC2014Z80/RC2014/.../cpm22.asm#L69 where cpm 2.2 is stored in the rom image which is copied into ram after power up. The person doing this missed a trick because it would have been better to store the cpm image in compressed form.
sdcc itself defines a memory map using areas. This has been quoted in several places already but I think it is poorly understood. areas are given an org to define where in the memory space they reside. You can define multiple areas with the same or overlapping address range to cover a memory space > 64k. The output from sdcc is an intel hex file which generates a representation of this memory space in a compact manner (ie no zero padding). You can use standard tools to turn this into multiple binaries.
z88dk's tools are more advanced. Internally it has a representation of any memory space which can be defined individually for each target. The output is processed through a separate program "appmake" that can turn this representation into a suitable output whether that be tape image, raw binaries, intel hex, snapshots, disk images and so on. But central to this is the SECTION, which is functionally the same as sdcc's AREA.
To see how it is done, here is a short example for the zx next. The zx next has several memory spaces but the most important is the organization of ram into 224 pages of 8k each. Each of these pages can be placed into any 8k range in the z80's 64k space. I don't want to get into details here but that should be enough information to understand this example.
In asm, I've placed some things into some of the 8k pages:
[свернуть]
Вы можете сделать то же самое для c - вы также можете скомпилировать c-код на определенные страницы памяти.Код:SECTION BANK_5 defs 2048,0xaa SECTION PAGE_30 defs 128, 0 defs 128, 30 defs 128, 0xff SECTION PAGE_41 defs 128, 0 defs 128, 41 defs 128, 0xff SECTION PAGE_125 defs 128, 0 defs 128, 125 defs 128, 0xff SECTION DIV_1 defm "DIV1", 0
«DIV_1» представляет собой память «divmmc». Память RAM-памяти zx next также может быть организована как 16k-страницы для совместимости с спектром 128k. Пространство PAGE и пространство BANK совпадают с BANK_5, что соответствует PAGE_10 и PAGE_11. Это называется BANK_5 здесь, потому что это то, как программисты спектра обычно понимают местоположение экрана. В этом случае 2k данных, присвоенных BANK_5, будут отображаться как вертикальные полосы на экране улы.
Простой пример, который проверяет содержимое этих банков во время выполнения:
Скрытый текст
You can do the same for c - you can compile c code into specific memory pages too.
"DIV_1" represents divmmc memory. The zx next's ram memory can also be organized as 16k pages for compatibility with the 128k spectrum. The PAGE space and the BANK space are the same with BANK_5 corresponds to PAGE_10 and PAGE_11. It's called BANK_5 here because this is how spectrum programmers normally understand the location of the screen. In this case the 2k of data assigned to BANK_5 will appear as vertical bars on the ula screen.
A simple example that verifies the contents of those banks at runtime is this:
[свернуть]
Вся программа скомпилирована в расширенный файл sna 128k, в который добавлены дополнительные банки памяти. Программа загружает дополнительные банки памяти при запуске с помощью функции «extended_sna_load».Код:#include <stdio.h> #include <stdlib.h> #include <arch/zxn/esxdos.h> #include <arch/zxn.h> #include <errno.h> void print_page(unsigned char page) { ZXN_WRITE_MMU3(page); // place the page into address range 24k-32k printf("Page %u\n\n", page); for (unsigned char *p = 0x6000; p != 0x6180; ++p) printf("%02x", *p); printf("\n\n"); ZXN_WRITE_MMU3(11); // restore bank 5 into address range 24k-32k } int main(void) { extended_sna_load(0); esx_f_close(0); if (errno) { printf("Error: %u\n", errno); exit(1); } print_page(30); print_page(41); print_page(125); return 0; }
Если я скомпилирую эту программу с z88dk без какой-либо обработки, выход будет представлять собой набор двоичных файлов, представляющих память:
Скрытый текст
The entire program is compiled into an extended 128k sna file that has the extra memory banks appended to it. The program loads the extra memory banks at startup using function "extended_sna_load".
If I compile this program with z88dk without any processing, the output will be a set of binary files representing memory:
[свернуть]
sna__.bin - main() in banks 5,2,0
sna__DIV_001.bin
sna__PAGE_010.bin
sna__PAGE_030.bin
sna__PAGE_041.bin
sna__PAGE_125.bin
Для sdcc вы вручную определяете области, охватывающие каждую из страниц в crt. Результатом будет один файл hex hex, а не набор двоичных файлов. Как вы извлекаете двоичные данные из файла hex hex, зависит от вас. Это не означает, что вам нужно получить один большой двоичный код с нулевым заполнением между областями.
Если я скомпилирую эту программу с помощью z88dk и запрошу расширенный sna как результат, результат будет следующим:
Скрытый текст
For sdcc you would manually define the areas covering each of the pages in the crt. The output would be a single intel hex file rather than a set of binaries. How you extract the binary data from the intel hex file is up to you. It does not mean you have to get one large binary out with zero padding between areas.
If I compile this program with z88dk and ask for an extended sna as output, the result is:
[свернуть]
sna.sna - 153k containing all the PAGEs and BANKs
sna__DIV_001.bin
Sna содержит всю память и готов к исполнению на реальной машине. Двоичный диск DIV по-прежнему является отдельным, поскольку пространство памяти «divmmc» не является частью «sna». Программа отвечает за получение этого двоичного кода в память при запуске.
В sdcc нет дополнительного шага для автоматического создания вывода правильной формы. Он имеет возможность определять пространства памяти в crt с помощью директив AREA. z88dk идет дальше с возможностью отделить «org» адрес от физической памяти (PAGE); это можно сделать с помощью PHASE, но лучше сделать это с помощью других средств, которые не мешают компоновщику.
Скрытый текст
The sna contains the entire memory space and is ready for execution on the real machine. The DIV binary is still separate because the divmmc memory space is not made part of the sna. The program is responsible for getting that binary into memory when started.
sdcc does not have an extra step to automatically generate output of the correct form. It does have the ability to define memory spaces in the crt with AREA directives. z88dk goes further with the ability to separate the org address from the physical memory location (PAGE); this could be done with PHASE but it's better done with other means that don't impede the linker.
[свернуть]
Последний раз редактировалось Alcoholics Anonymous; 01.06.2018 в 19:33.
Я поппытался решить эту проблему в SDCC-NOINIT. В процессе (ещё до конца не доделано).
Идеология такая: имеется "перемещаемая библиотека", которую можно загрузить с любого адреса, кратного 0x100. Она содержит в себе функции и таблицу перемещений.
При загрузки библиотеки она настраивается на адрес загрузки.
В основной программе хранится специальная маленькая процедурка, которая позволяет вызвать функцию по любому адресу. Эта процедурка настраивается при загрузки библиотеки.
То есть библиотека представлена в виде двух файлов:
1. Загружаемый .bin модуль - собственно библтотека.
2. Встраиваемая в основную программу часть библиотеки .rel.
Вызов функций из основной программы - прозрачный. То есть не надо самому переключать странички, что-то настраивать. При загрузки библиотеки всё настраивает загрузчик.
В принципе - работает. Но есть нюансы.
Самое сложное было автоматизировать генерацию кода для вызовов. Но bash справился
Да чую мне проще будет накалякать нужный код на ужасме и бинарь потом в нужный адрес пихать, чем тут парится. z88dk вообще не вариант и никогда не будет вариантом.
Там не важно С или АСМ.
Таблица перемещения генерится автоматом.
Если программа многостраничная, то накладные расходы не велики. Зато удобство.
Проблема сейчас как это хорошо совместить с менеджером памяти.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием