Основная проблема заключается в люди не знают, как писать библиотеки. Они используются для популярных монтажников на спектр, которые "маленькая машинка мышление" и не имеют связей возможности.Сообщение от Oleg N. Cher
Последовательную компоновку, безусловно, является особенностью sdasz80 и о нескольких других Z80 монтажников, как z80asm в z88dk и сборщиком в Binutils. Эти сборщики только приложить код из библиотек, которые действительно используются в программе. В z88dk мы зависим от него, потому что у нас есть более чем 64К кода и данных в библиотеке спектра, например, и если последовательную компоновку не работал, даже такой программы, как "основной () {}" будет сильному нажиму, чтобы соответствовать в 64k
Та часть, которая ловит людей в том, что все связующие работать в единицах модулей, что соответствует отдельных файлов. Библиотека код должен быть разбит на самых маленьких функций, которые имеют смысл и те отдельные функции должны быть, содержащихся в их собственных файлов. У нас есть более 5000 в z88dk и хотя вы говорите, было бы сойти с ума, чтобы сделать это, это на самом деле лучший способ делать вещи. Одна вещь, вы найдете, как ваши библиотеки ASM расти в том, что объем памяти является проблемой. Вы хотите, чтобы ваш код библиотеки для повторного использования столько кода, сколько возможно. Вы же не хотите, например, пять различных умножения процедуры, потому что пять различных библиотеки встроены собственную умножения. Эти крошечные подпрограммы должны быть доступны как правило, и используется все, чтобы снизить конечную размер бинарного кода, и это достигается только, когда вы пишете библиотеки разбитые на мелкие кусочки. Головная боль вы получили от создания библиотеки Лазерная Basic в основном потому, что вы должны были развалится чужой монолитный каплю, и это не приятная задача, ни интересным. Но если вы пишете с нуля, это очень простой и хороший способ организовать исходный код.
Ваш "умный связывание" идея еще один шаг вперед, но он никогда не будет получить много сцепление с не-объектно-ориентированных компиляторов просто потому, что описанный выше метод лучше для своих библиотек, поскольку позволяет максимально повторное использование кода и лучшей организации исходного кода.
Я могу говорить с этим, написав тысячи библиотечных функций, что есть только недостатки в письменной форме код библиотеки с более чем одним библиотечной функции в одном файле.
Я вижу, где вы можете сделать это для создания библиотеки с использованием языка высокого уровня. Но для императивных языков, таких как C, я все еще думаю, что это предпочтительно делать библиотеки в том же порядке, одну функцию для каждого файла. Вот пример с примитивным дискового ввода / вывода для копий в минуту: http://z88dk.cvs.sourceforge.net/vie...src/fcntl/cpm/
Даже для абстрактных типов данных, которые эффективно объектов, это все еще хороший способ организовать код. Вот реализация векторного <char>:
http://z88dk.cvs.sourceforge.net/vie.../b_vector/z80/
Как это обычно бывает в C, обзорный делается с помощью искажение имени. "Asm_" показывает, что функция непосредственно вызывается из собраний, "b_vector_" делает все эти функции "методы" вектора "объекта" байт. Все "методы объекта" находятся в одной директории, так же, как все функции, реализующие + + объект C, как правило, быть в одном файле.
Я думаю, что это лучший способ организовать код так. Конечно положить все эти функции в один файл и имеющие компилятора раскол его на части не имеет никаких преимуществ вообще и намного хуже с организационной точки зрения.
Я думаю, что "умный связывание" начинает иметь смысл, когда вы начинаете смотреть на объектно-ориентированных языках. Тогда имеет организационную смысл иметь все функции, реализующие объект в одном файле. Тогда вы хотите, чтобы компилятор пойти туда и забрать его на части для компоновщика, чтобы каждый метод объекта индивидуально связаны против. Способ сделать это, чтобы иметь компилятор соответствующим калечить имена, чтобы обзорного правила еще можно повиновался, когда отдельные методы объекта сделаны глобальные для компоновщика.
== english ===
The main problem is people do not know how to write libraries. They are used to the popular assemblers on the spectrum which are "small machine thinking" and do not have linking capability.
Incremental linking is certainly a feature of sdasz80 and of a few other z80 assemblers like z80asm in z88dk and the assembler in binutils. These assemblers will only attach code from the libraries that are actually used in the program. In z88dk we depend on it because we have more than 64k of code and data in the spectrum library, for instance, and if incremental linking did not work, even a program like "main(){}" would be hard-pressed to fit in 64k
The part that catches people is that all linkers work in units of modules, which corresponds to individual files. Library code must be broken into the smallest functions that make sense and those individual functions must be contained in their own files. We have over 5000 in z88dk and although you're saying it would drive you nuts to do that, it's actually the best way to do things. One thing you'll find as your asm libraries grow is that memory space is a problem. You want your library code to reuse as much code as possible. You do not want, for example, five different multiply routines because five different libraries inlined their own multiply. These tiny subroutines must be made available generally and used by everything to reduce the final binary size, and this is only achieved when you write libraries broken into small pieces. The headache you got from creating a Laser Basic library is mainly because you had to break apart someone else's monolithic blob and that's not a pleasant task nor an interesting one. But if you write from scratch it's a very simple and good way to organize source code.
Your "smart linking" idea is going one step further but it will never gain much traction with non-object-oriented compilers simply because the method described above is better for their libraries as it enables maximum code reuse and better organization of source code.
I can speak to that, having written thousands of library functions, that there are only disadvantages in writing library code with more than one library function per file.
I can see where you may want to do this for making libraries using a high level language. But for imperative languages like C, I still think it is preferable to make the libraries in the same manner, one function per file. Here's an example with primitive disk i/o for cpm: http://z88dk.cvs.sourceforge.net/vie...src/fcntl/cpm/
Even for abstract data types, which are effectively objects, it's still a good way to organize code. Here's an implementation of a vector<char>:
http://z88dk.cvs.sourceforge.net/vie.../b_vector/z80/
As is typical in C, scoping is done using name mangling. "asm_" indicates the function is directly called from assembly, "b_vector_" makes all these functions "methods" of the byte vector "object". All "object methods" are in one directory, just as all functions implementing a C++ object would typically be in one file.
I think that's the best way to organize code like that. Certainly putting all those functions into one file and having the compiler split it apart has no advantage at all and is much worse from an organizational point of view.
I think "smart linking" begins to make sense when you start looking at object oriented languages. Then it makes organizational sense to have all the functions implementing an object in one file. Then you want the compiler to go in there and pick it apart for the linker so that each object method is individually linked against. The way to do this is to have the compiler suitably mangle the names so that scoping rules can still be obeyed when individual object methods are made global for the linker.
Ответить с цитированием