assembler

[region]

Кто каким пользуется?

насм масм фасм и т.д..

[Olmer]

Ты язык с компилятором не путаешь, не?

[Payne]

Блокнот :-D

[region]

:fool: если писать под насм то в масм его не скомпилируешь
Payne, в RadAsm удобней xD

[Payne]

Есть еще TASM и оператор asm..end в Паскале и Делфи

[Kenny]

Учится кстати хорошо на emu8086.

[Payne]

Есть хороший курс уроков Калашникова, очень всё понятно описано и по возрастанию сложности: http://www.kalashnikoff.ru/Assembler/
Не рекомендовал бы для новичков такие книги как В. Юров "Assembler. Учебник" и иже с ними

[region]

Payne, Калашникова книга оч старая меня масм32 10 версия а там 6.1 не только синтаксис другой вообще бред, проще http://www.codenet.ru/progr/asm/newbee/

[region]

вот обычная прога на асм под вин32, 2.5кб окно

скомпилировал на MASM32

[[TEQUILA]]

офф:
ну я тебе на дотнете тоже сделаю мааленький экзешник :) А фреймворк щас есть в каждой винде
ИМХО сейчас, с нашими объемами ОЗУ, это все уже не актуально

[region]

[TEQUILA], асем это не эмуль прямая работа с ОС а не бред подобное .net
.Net это то что не стоит использовать вообще! к примеру если открыть делфи создать просто окно оно будет 536кб весить, и в ОЗУ 3мб
:crazy: ассем очень актуален по скорости

с нашими объемами ОЗУ, это все уже не актуально

угу, однако мелкая софтинка которая почти ничего не делает ест 70 озу и проц нагружает что всё винит ну ну )) к примеру CommFort чат ))) :pleasantry:

[Harmer]

Э... 2 килобайта на пустое окошко?
Ну, тебе есть куда расти. http://demoscene.ru/demo/demo1a.php3?2010

[region]

2кб так много из-за юзания API виндовс поэтому так много, а люди пишут 3Д работая напрямую с видеоадаптером (видеопамятью) поэтому сцены такие)

[Payne]

region, я просто этим уже очень давно занимался, сейчас не до ассемблера.

2кб так много из-за юзания API виндовс поэтому так много, а люди пишут 3Д работая напрямую с видеоадаптером (видеопамятью) поэтому сцены такие)

Эээ-нет, 2 килобайта - это из-за того, что в "пустой" программе на Делфи указано множество библиотек в разделе uses. Они ссылаются на объекты и компоненты, которые могут даже не использоваться, но память под них выделяется. А если убрать все это из uses и писать окошко, пользуясь лишь средствами Windows API, то памяти оно будет занимать примерно столько же, сколько и написанное на асме идентичное окно. Или совсем чуть-чуть больше.

Я как-то программировал, читая книгу М. Краснова об использованияя OpenGL в Delphi, там изначально он сделал акцент на то, что окна создаются при помощи API, а далее работа идет напрямую с графической библиотекой, без использования вообще каких бы то ни было объектов и компонентов Delphi. Приложения получаются очень компактными. И с таким же успехом можно, к примеру, делать окна на асме под Windows. Только OpenGL, к примеру, в делфях гораздо проще подключить.

[VasyaPupkin]

[TEQUILA], асем это не эмуль прямая работа с ОС а не бред подобное .net
.Net это то что не стоит использовать вообще! к примеру если открыть делфи создать просто окно оно будет 536кб весить, и в ОЗУ 3мб
:crazy: ассем очень актуален по скорости

Уж сколько раз обсуждалось: все зависит от задачи.

З.Ы. Хотя фреймворки мне и самому не нравятся, но кушать-то хочется... :(

[region]

Payne, в делфи никогда не сделаешь голое окно даже на API оно как минимум будет 25кб , в пустом проекте от делфи там огогого сколько мусора... там нужно после компиляции готового проекта долго вычищать то что не используется, через отладчики =)

VasyaPupkin, любая задача будет решаться быстрей на асм ) фреймворки это маздаевское извращение, на Windows mobile 6.5 обычное окно на .net запускается 2сек, и написал на с++ запустилась мгновенно, "время в миллисекундах"

[Payne]

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

[[TEQUILA]]

region,

Если начали вспоминать холивары «какой язык программирования круче», добавлю-ка я и свои пять копеек. В 1998 году случилась эталонная ситуация для подобной проверки.

Лос-Анджелес. Монтируется аппаратура на корабле. Задача — принять телеметрию и отобразить в нужном виде на экран. На корабле три изолированных по национальному или производственному признаку сегмента, куда «чужих» не пускают. Отображением в одном сегменте занимался я, в другом — американцы из фирмы «A. S.», в третьем — программеры из рабоче-крестьянской корпорации. Задачи были весьма схожи: принять, обработать, отобразить. Отображение требовалось разное, но это уже неважно.

Американцы не задержались на корабле больше недели. Приехали, поставили софт, запрограммировали, получили бабки, уехали. Тихо-мирно, молча. Никаких претензий, никаких проблем. Язык программирования — Visual Basic.

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

Программеры рабоче-крестьянской корпорации приехали вместе со мной, но встречали Новый год вдали от дома. И Старый Новый год — тоже. Потом я просто перестал за этим следить. Язык программирования — Visual С++.

Для себя из этой истории я вынес критерий оценки собственной работы: количество усилий, потраченных для решения задачи, разделённое на количество заработанных килобаксов. Если сидишь на окладе, сложных проблем не возникает и нет особой нужды решать проблему быстро, то С++ вне конкуренции — программу любой сложности можно писать и отлаживать практически вечно, регулярно получая оклад. Если присутствует элемент сдельщины, то к С++ надо прибегать в последнюю очередь. Ведь крутизна программера — не в синтаксисе исходников, а в толщине его кошелька.
(C) iTHappens.ru

.NET вне конкуренции

[region]

[TEQUILA], не совсем понял направленность тут о с++ и не о с#

[[TEQUILA]]

region, я просто к тому, что выбор языка диктует не его быстродействие (которое на глаз не увидишь), а эффективность и скорость разработки. А тут .Net выигрывает

[VasyaPupkin]

VasyaPupkin, любая задача будет решаться быстрей на асм ) фреймворки это маздаевское извращение, на Windows mobile 6.5 обычное окно на .net запускается 2сек, и написал на с++ запустилась мгновенно, "время в миллисекундах"

[TEQUILA] уже за меня ответил. Если не согласен, предлагаю спор: написать простенькую программу для отображения данных из таблицы. Ты на ассемблере, я на Delphi (или C#). Все с нуля, без заготовок. Как думаешь кто из нас быстрее напишет? :)

З.Ы. И по поводу "маздаевского извращения" - java-то раньше появилась. ;)

[Пресс]

region, VasyaPupkin, ура!!! баттл!!! :yahoo:
Давайте [TEQUILA] поставит задачу, а вы посоревнуетесь.
[TEQUILA], Серёга :clapping: есть возможность нахаляву получить программу для ПФ ;)

[region]

VasyaPupkin, угадай и укого из нас программа будет работать быстрей ? ))

Скорость разработки ассемблер конечно так сказать самый долгий, но самый быстрый в работе, а делфи медленные но быстрый в разработке (нет смысла сравнивать)


И асм нужно учить не для того чтоб писать что то постоянно, а чтоб понимать как всё работает

[VasyaPupkin]

VasyaPupkin, угадай и укого из нас программа будет работать быстрей ? ))

У тебя. Но самое обидное (для тебя :blum: ), что мы этого даже не заметим. :)

[Пресс]

Запускать будем с дискеты на моём ноуте P-100, 32 Кб оперативка, 2 Кб - видео
Виндовс 98, экран 800 на 600.

[[TEQUILA]]

Отлично. Ставлю задачу - прога должна отправлять в очередь WebSphere MQ и забирать из очереди произвольный XML файл :)

[fernir]

О, ассемблер вспомнили :) Прям ностальгия по институту. Когда с MASM баловался. region, не пойму почему ты их считаешь разными ассемблерами. Ведь язык ассемблера это язык процессора, он одинаков для данного процессора или иногда семейства, а все различия MASM, TASM в директивах компилятора.

И асм нужно учить не для того чтоб писать что то постоянно, а чтоб понимать как всё работает

З.Ы. Хотя фреймворки мне и самому не нравятся, но кушать-то хочется... :(

Вообще согласен с этими двумя концепциями, кроме того что фреймворки мне нравятся. Это примерно как на собеседованиях в бай эрия или силиконовке вас скорее попросят рассказать алгоритм бубль-сортировки или оценить сложность какого-то рекурсивного алгоритма, вместо подробностей по LINQ или WCF, а потом, если возьмут 90% времени будете ковырять эти самые LINQ, а не алгоритмы. Так что ассемблер для развития ума это хорошо, но вот им пользоваться при решении бизнес-задач маловероятно. Насколько я понимаю, ассемблер сейчас в редких случаях используется в системах реального времени, низкоуровневых задачах или во всяких микроконтроллерах. Хотя эти задачи, с ограничением для микроконтроллеров, можно успешно решать на тех же сях.

Про .net не соглашусь, это классная вещь. Это даже больше чем фреймворк, скорее это концепция с инструментарием в виде библиотеки классов и среды исполнения (фреймворка). Почему бы не сделать Assembler .Net :) Правда под мобилы на нете не пробовал писать, если штука с двумя секундами правда, то получается что CF скорее маркетинговое решение, чем технологическое. На сколько я знаю Iphone вообще рубит все что больше 15 сек тормозит. В общем для мобил секунды это действительно много.
А вообще в большинстве случаях не стоит переоценивать значения параметра "производительность", есть и другие более важные критерии: правильность, предсказуемость, стоимость, технологичность, сопровождаемость которые можно поставить немного выше производительности.

[Olmer]

ИМХО, писать ныне под x86 на асме - чистейшей воды мастурбация. Даже на AVR или PIC результирущий код после компиляции asm и С примерно одинаков по объему и быстродействию. "Чистый" asm имеет смысл лишь в случае необходимости максимально точно следить за _временем выполнения кода_, а не за его быстродействием. А тогда уж можно и непосредственно hex написать. :) Но временные затраты на обучение и понимание правильного программирования отдельно взятой модели контроллера могут быть слишком велики, и пока вы будете разбираться с тонкостями записи во все регистры у Меги, например, её уже с производства снимут.
Так что пишите хоть на Бейсике, лишь бы всё правильно работало. :)

[region]

[TEQUILA], я не говорю что ООП кака, а вот почему ты не любишь асм? если ты его не знаешь то можно выучить там всего 25 команда )))

fernir, Команды асм одинаковы, но синтаксис с итд разный....


иногда асм требуется в оч сложный прогах, к примеру написать низкоуровневую библиотеку, а далее уже использовать её в делфи и наслаждаться )
по поводу .net если запускать на ПС то с виду невозможно определить насколько это убожество тормозит, открывается мгновенно, а вот тоже самое у меня на КПК с 417Мгц (ОЗУ 64мб) по той же технологии но с задержкой в 2 сек и это только пустое окно, попытка к примеру написать на .net так называемую звонилку когда поступает вызов прога запускается показывает что звонят и т.д ожидание в 2 сек и больше это очень много...

(ну на мобиле конечно .net урезан множество функций классов нет)

сказать что КПК слабый нет написал на С++ на API так как ООП нету, программка очень быстрая как и с графикой с прорисовкой, так и открытие меньшее 1 сек, жмёшь стилиусом сразу открывается

Olmer, ну не совсем мастурбация а вот изучить как работает программа на асм это нужно так как скомпилировав проект на С++ в некоторых места к примеру будет зависания или ещё что то, а вот через отладчик будет ясно видно что не так, а без знания асм смотреть в отладчик бред )

[Andreyka]

по поводу .net если запускать на ПС то с виду невозможно определить насколько это убожество тормозит, открывается мгновенно, а вот тоже самое у меня на КПК с 417Мгц (ОЗУ 64мб) по той же технологии но с задержкой в 2 сек и это только пустое окно, попытка к примеру написать на .net так называемую звонилку когда поступает вызов прога запускается показывает что звонят и т.д ожидание в 2 сек и больше это очень много...

А по моему в течении 2 секунды на кпк запускается сам .net (со своими библиотеками и потрохами), а не твоя программа... Для чистоты эксперимента надо было менюшку сделать, картинки на экран по выводить, какой-нибудь алгоритм сортировки погонять:) И сравнить разницу в производительности.

А звонилку я бы вообще не выгружал из памяти, тогда задержки на запуск приложения при приеме звонка в принципе не будет :rolleyes:

На мой взгляд assembler вещь полезная, но уж очень узкоспециализированная.