Стандартная библиотека для ассемблера

Почитал я тему "высокие языки" и решил: "Нужна стандартная асм-библиотека". Ведь нельзя не согласиться с тем, что обидно, когда ты напишешь какой-нибудь ФТП-сервер на асм, а какой-нибудь ламер сделает то же самое (даже качественнее) на Дельфи, шлёпнув компонентой по форме.

Если наберётся достаточное количетво добровольцев, можно будет начать (если нет - проект будет свёрнут). Библиотеку можно даже сделать переносимой (что, правда труднее...).

Предполагается сделать следующие модули:

1. Работа со строками.

2. Длинная арифметика.

3. Конвертирование чисел(строка->целое число->дробное числ) - каждое в каждое. Короче, все поняли.

4. Сортировки (хоть одну, но оптимизированную)

5(нет). Отдельного модуля работы делать не предполагается, ибо в апи и так всё неплохо. Хотя можно и сделть вызов апи-функции+слежку за всеми указателями(чтоб ничего не потерялось) или для переносимости (как в Си).

6. Работа с файлами и каталогами (+поиск)-уж больно в апи всё запутано.

7. С сокетами всё прикольно. Но можно сделать (свои) функции работы с FTP, HTTP, POP, SMTP и проч. (типа HTTPDownload(LPSTR url,LPSTR toFile))

8. Обработка исключений - ни в коем случае. С трудом представляю себе альтернативу.



Может ещё что-то забыл - добавьте или добавлю. Если хотите приконнектиться - пишите сюда. Чем юольше нас - тем проще. И помните это нужно не мне - это нужно всем.

 

Конечно я не профи в програмировании и времени не куча, но ради такого дела можно и помочь.

 

Итак, загибаем пальцы - раз.

 

dmit10

Мое имхо: пункты 1-4 идут с масмом; 5 - не совсем понял идею с указателями; 6 - а что там сложного?; 7 - мало кому надо, а тем кому надо все имеют.



Для ассемблера такие библиотеки не имеют смысла. Я бы ни за что не использовал код, написанный не мной лично для чего-то серьезного. По крайней мере без долгого тестирования (но за это время я сам все напишу скорее всего).



Может поискать другое применение неуемной энергии?

 

> Я бы ни за что не использовал код, написанный не мной лично для чего-то серьезного. По крайней мере без долгого тестирования



Точно. Я например ни разу не воспользовался masm32.lib, да и в исходники её всего пару раз смотрел

 

Кстати, да. При создании моей скромной коллекции кода использовались материалы с этого форума. Здесь проплыывали как-то и работа со строками и преобразования строк-чисел. Я эти примеры утягивал, разбирался что да как, модернизировал так, как я думал будет лучше и запихивал на склад. Периодически при работе с ними возникают всякие новые мысли касательно кода и приходится править. В конце-концов многие функции стали уже не похожи на то, что было в начале ни одним байтом. Начальные функции просто давали толчок, т.к. самому придумывать общеизвестный алгоритм немного лень.



Насчет сортировок все сложно. Сортировок разных много, но действительно хороших - не больше пяти. Но эти сортировки разработаны для массивов, а массивы не есть гут. Я лично обычно для своих временных данных использую списки (односвязный или двусвязный), которые доблестно заделал. Вот разберусь с сессией и заделаю что-нить посложнее: Б-дерево, 2-3 дерево, хэш-таблицу, и т.д.. И вот тогда наступит счастье, потому что можно будет в своих прогах для временных данных использовать, например, сбалансированое дерево и тогда надобность в сортировках отпадет сама собой, а время доступа к элементу увеличится очень серьезно.



Для больших чисел арифметику я когда-то писал на сях - это был курсовой по сям в универе. С тех пор ниразу не пользовался не то чтобы наработками, но даже самими идеями, т.к. слабо представляю себе задачу, в которой не достаточно 32 разрядов.. По крайней мере, в повседневных задачах таких точно нет.



Преобразование типов данных - это да. Это надо. Но на форуме такая тема пару раз поднималась и там есть очень хорошие функции. Причем, универсальные.



Когда я говорил про библиотеки стандартные, я говорил про нечто вроде сишного CRT - комплексная библиотека. Но та же CRT дает очень много плохого. Например, 50к лишнего кода. За скорость разработки платим скоростью работы и размером модуля. Согласен, для проектов на 10 метров ни тот ни другой критерий не существеннен, но в таких проектах тоже много асма в узких местах. Не потому ли, что CRT мешает? Ведь компилятор хоть и дурной, но оптимизирует достойно.



Так что идея общей библиотеки для асма не будет успешной, имхо. Все-таки громадная разница между асмом и hll и то, что в hll хорошо и нормально, в асме неприемлемо.



Это, конечно, имхо, но думается, со мной многие согласятся.

 

Я использую собственную библиотеку, где есть все, о чем написано выше. Недавно глянул в masm и нашел тем тоже процедуры Прилеплю наверно и их.

Все это повышает Скорость разработки программы на ассемблере. Ну а то, что Код растет (у меня минимум 17 кб.), можно пока потерпеть, а потом придумать что-нибудь с макросами, что б отключали неиспользуемые функции.

 

yureckor

что б отключали неиспользуемые функции

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

 

наличие собственной библиотеки очень удобно. и для начинающих тоже, поэтому было бы неплохо, чтобы кто-нибудь потратил капельку своего драгоценного времени и написал краткую статью для лиц, не имеющих спец образования (к коим отношусь , как грамотно сделать для себя такую библиотеку.

 

Дык что вы все

ругались на отсутствие такой библиотеки, а как дошли до дела - на попятную



([quot]>Основная причина - отсутствие соответствующих библиотек.

Что однако вовсем не уменьшает проблемы. Не могу ж я заказчику сказать "извиняйте, под АСМ нифига не написано. Ждите."[/quot])

 

dmit10

Лично я не ругался. Я говорил, что нет СТАНДАРТНЫХ библиотек. Но у каждого программиста ОБЯЗАНЫ быть свои наработки. Количество и качество ЭТИХ нароботок и влияет на скорость разработки, а вовсе не количество и качество СТАНДАРТНЫХ. Причины были объяснены выше.

 

shoo

грамотно сделать для себя такую библиотеку

Применительно к "отключали неиспользуемые функции" надо оформлять каждую функцию как отдельный объектный файл.

 

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

 

ДА!!! Именно так! (Хоть один человек меня понял). Если ты написал функцию, которая может пригодиться в дальнейшем, то почему бы тебе не поделиться с другими? Ведь необязательно подключать библиотеки, можно же просто копировать код (в большинстве случаев я так и делаю).



Вот пусть есть задача: прочитать 2 числа (пусть даже по модулю не превосходящие 2 000 000 000, знаковые) в текстовом файле (в том смысле, что числа записаны как строки). Нужно вывести их сумму в выходной файл (тоже текстовый).



Решение без библиотек:

1.вызвать соответствующие функции АПИ работы с файлами для прочтения содержимого. Проблема(по кр. мере для меня): там слишком много параметров(зачастую редко используемых), я никак не могу запомнить, что и в каком порядке нужно указывать.

2.написать функцию перевода из строки в число. Проблема: тратится лишнее время, больше вероятность допустить ошибку и т.п.

3.аккуратно перемножить (предусмотреть случай выхода за 4 байта). Соглашусь - этот пункт простой.

4.написать функцию обратного перевода. См. пункт 2.

5.Записать это всё в файл.



А слабо сделать это бысто и качественно?



Решение с библиотеками:

пп:1,2,4,5-вызов стандартной функции (и действительно, как заметил shoo, её код можно просто скопировать, а не мучаться с линковокой)

п.3 - и так всё просто.



Вот и всё. Надёжность? Если нас будет много, то каждый, просмотрев код функции оставит свои замечания, поправки (как говориться: одна голова - хорошо, 2 лучше), будет большое число тестеров(нас же). Скорость разработки: из примера всё видно.



Библотека будет представлять собой набор исходного высококачественного кода, который можно свободно копировать и использовать.



nOp

Нравятся деревья - сделаем и сортировки, и Б-деревья. И сжатие и кодирование (напр. по md5). Не в этом вопрос...

 

К сожалению, весьма затруднительно сделать "стандартную библиотеку для ассемблера" так как не существует "стандартного ассемблера". Например, в некоторых ассемблерах метки могут означать либо адрес, либо данные по этому адресу, в зависимости от того, в какой инструкции используется метка; в других ассемблерах метка всегда означает адрес независимо от инструкции. Другая абсолютная несовместимость это так называемые intel-syntax и at&t-syntax.



По этим причинам невозможно определить даже некоторый "базисный ассемблер", под который можно было бы разрабатывать библиотеку. Это означает что под каждый компилятор придётся разрабатывать свою библиотеку. Фактически, так и делается. Например, вместе с masm идёт библиотека, каторую можно назвать "стандартная masm-библиотека"...



В последнее время на форуме часто звучат возгласы типа "ООП must die, component programming rulez!" Возможно, разработать некоторую компонентную архитектуру специально для ассемблера было бы действительно полезно...

 

Ну хорошо - выберем синтаксис для каждой ОС (из тех, под которые делаем) - любые конструктивные предложения проверяются и учитываются...



Можно сделать переносимые функции, как в Дельфи, можно не делать.... Вариантов много - нужны люди

 

captain cobalt

К сожалению, весьма затруднительно сделать "стандартную библиотеку для ассемблера" так как не существует "стандартного ассемблера". Например, в некоторых ассемблерах метки могут означать либо адрес, либо данные по этому адресу, в зависимости от того, в какой инструкции используется метка; в других ассемблерах метка всегда означает адрес независимо от инструкции. Другая абсолютная несовместимость это так называемые intel-syntax и at&t-syntax.



Это-то как раз проблема решаемая. Какой-нить метаассемблер, единственная функция которого в генерации листингов для других ассемблеров - самое то. На эту тему Эдмонда лучше допросить. А конвертер Intel->AT&T для DJGPP я еще лет 5 назад видел.



captain cobalt

В последнее время на форуме часто звучат возгласы типа "ООП must die, component programming rulez!" Возможно, разработать некоторую компонентную архитектуру специально для ассемблера было бы действительно полезно...



Было бы здорово, но идея наверняка наткнется на суеверие "а, ламеры будут компоненты на формы кидать, маздааай". Ну и пусть кидают, нам что, жалко?

 

Всё это хорошо, кроме некоторых моментов.

Даже подключая готоые библитеки, иногда с опаской внимательно смотришь, как ониработают.



Простое копирование — это самый быстрый способ наплодить тараканов. Не разбираясь в коде, не учитывая контекст и специфику его копировать его к себе — это, мягко говоря, рискованно.

Это конкретная задача и не стоит надеяться, что найдутся функции/библиотеки "на все случаи жизни".

Те описанные "проблемы" с её решением — это всего лишь от малоопытности. Которая проходит, если не лениться.



Кстати, подобные задачи быстрее реализовать, чем искать готовую функцию и разбираться, как её использовать.

 

IceStudent

Мысли читаешь!



dmit10

Ну, во-первых, на этом форуме много разных стандартных функций было, как я уже говорил. Надо только найти и переделать под себя.

Переделывать под себя все-равно придется.

Во-вторых, как уже говорили, не всегда язык реализации совпадает с желаемым. Я, например, использую фасм. А негласным стандартом пока что является масм - на нем больше людей программирует. Разница в этих ассемблерах не очень большая (с точки зрения исходника, есесна), но ключевые моменты отличаются (адресация, внутренние метки и т.д.).

В-третьих. Каждый человек использует/неиспользует свой набор макросов. Вроде как мало народу, которые юзают стандартные макросы. Так что так и так, скачав код, надо разбираться в нем и переделывать под свои макросы. Лично я, например, макросы вообще не использую (кроме импорт/експорт). Никаких инвоков и тем более ифов/свитчей. А кому-то нравится. И что мне прикажете делать, если скачаная процедура больше похожа на Си, чем на асм?



Вот идея мета-языка и его интерпретатора мне понравилась. Даже не обязательно знать псевдокод, на котором написана процедура - интерпретатор сам изготовит листинг на требуемом языке. НО. Кто этим займется? Я бы мог кое-чего, но у меня сессия. Эду итак забот хватает. Задача-то достаточно сложная, это вам не это. Нужны люди, знающие какой-то ассемблер до последней запятой. Таких людей мало по определению "абсолютного знания". Так что в любом случае интерпретатор не сможет переварить некоторые моменты. В любом случае придется править листинг. Можно, конечно, сделать максимально настраиваемый интерпретатор, чтобы можно было вплоть до конструкций псевдокода расписать что да как делать. Но...



Вот перечитал предыдущий абзац, и поумал, что такой интерпретатор - шаг к сям. Немного не за то боремся..



_________________

Резюмируя вышесказаное считаю целесообразным изложить свое ИМХО.

ИМХО, не надо суетиться, а главное - лениться. Вместо того, чтобы часами рыскать по форумам в поисках какой-нить функции, было бы не лишним взять Д. Кнута и найти там описание нужного алгоритма. С псевдокодом, заметьте. Ну а дальше все просто.

Вот скажите, зачем я сейчас сижу и пытаюсь осмыслить 2-3 дерево? Чтобы завтра сдать лабу? Да. Но я мог бы найти в инете нужный код и собрать его в кучу. Просто я ХОЧУ знать как ВСЕ устроено. Но чтобы осилить реальные алгоритмы, которые используют профессионалы, надо сначала понять как пузырьком массив сортировать.



Все-таки, мое мнение, что хотите компонентного программирования - велкам ту Де#фи. Хотите ООПа - велкам ту Цэ++. Хотите знать и уметь все, что можно на любом языке и кроме того знать и уметь то, чего на других языках нельзя - велкам ту Асм.



Копирование чужого кода без тотального разбирательства и модернизации - обман самого себя и провал в знаниях.

 

Согласен с nOp'ом.

И все же библиотека не помешает. Ламеры на ней писать не смогут, а если нужно- а нету и время жмет- можно взять кусок, ну а уж потом написать свой.

IMHO- например сокеты и пр.- это ж геморой тот еще, зачем асм'овцу под Виндовоз разбираться еще как работает и глючит Виндовоз так низкоуровнево? Подключить и не парится.

Хочешь настоящего Асма- читай протокол передачи и пошел.