Первая программа на ассемблере.

А вот интересно, правда ли что почти все начинают написание программ с Hello World!
Я сам начал со вставок маш. кодов в свои проги на Бейсике (еще под процессор К580 :-), попутно освоив и ассемблер. Затем перенес несколько программ на x86. Но свою, именно на асме, написал только для своей двойки. Использовалась в батниках для вывода цветного текста, очистки экрана, подачи звука, опроса клавиатуры и еще чего то по мелочам. И весила при этом два байта Впрочем и сами батники я создавал с помощью тасма, но это уже были вторая и тд. программы

AndNot
Какая именно первая программа на ассемблере была не помню, точно не Hello World. Просто точно сказать не могу что было первым. Взялся за что-то серьезное, толи бут сектор толи чего-то другого. Помню начинал с асм вставок для программирование VESA, мышки и еще чего-то там. Сейчас вот тенденция в сторону машинных кодов растет, не хватает мне встроенного ассемблера в паскале.

Я начал постижение ассемблера с вывода простого MessageBox. Под DOS я асмом не увлекался - клепал феньки на TP...

Маш.коды

причем не на ассемблере а именно маш.код где JMP=0xC3
когда появился именно ассемблер(к580) то воспринимался как Бэйсик после асма

А я делал курсовой проект на ассемблере "Декодирование кодов Хемминга" на ЕС1020.

Цитата ЫукпШ @ 04.02.07, 02:20

А я делал курсовой проект на ассемблере "Декодирование кодов Хемминга" на ЕС1020.

У нас была ЕС1035 , но этот период програмисткой деятельности я в учет вообще не беру, ибо было все в обязаловку(а лишь бы сдать) и соответсвенно ни какого творческого интереса в возне с перфокартами (б-р-р-р, странно как вообще не отбили интерес к этому делу)

Цитата AlexJ @ 04.02.07, 03:29

.. ни какого творческого интереса в возне с перфокартами ..

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

Сообщение отредактировано: ЫукпШ - 04.02.07, 05:47

Я начинал с машинных кодов для процессоров К580 и Z80 (ПК Специалист и ZX Spectrum), программы ассемблера для этих ПК не взлюбил, эфективнее было писать сразу в машинных кодах (была такая програмка "MONITOR" называлась), таблицу 580 знал на память, а сейчас мне без MASM-а не обойтись.

Первая софтина была нагло передрана с книжки Финогенова "Самоучитель по системным функциям MS-DOS". Ниче не делала, грузилась, настраивала DS и уходила по 4Ch/int 21h. Дальше были вывод на экран, файлы, графика (CGA, ибо юзал тогда еще "Поиск 1.03"), резиденты, обработчики прерываний... и т.д.
зы Голосовал за хелловорлд.

унас был в универе курс асемблера
под досом писали простые проги = )
но не хелло-ворлд

У мя первый был драйвер ps/2 мыши, не через int 33h, а именно аппаратный
С Кулаковым разбирался.
А потом в хард так и потянуло...

а у меня было не "хелоу ворлд!", а "ПРЕВЕД СЛАВОН!"


ЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫ

Помогите сделать драйвер клавиатуры на ассемблере через порты ввода-вывода

Basic-> Pascal-> Asm-> Code (машинные)

Цитата antelv_01 @ 14.02.07, 20:18

Помогите сделать драйвер клавиатуры на ассемблере через порты ввода-вывода

Отчего же не помочь, только не в этой теме

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

Цитата e-moe @ 25.02.07, 15:44

Просто написал на листике формулу и начал ее кодить на асме.

Такой вариант даже в голову не пришел Хоть кто то "по правилам" сделал

Цитата AndNot @ 25.02.07, 16:40

Такой вариант даже в голову не пришел Хоть кто то "по правилам" сделал

просто асм был не первым языком программирования который я учил...

AndNotчто-то, только заметила тему , а что первое... ты прикинь не помню

Первую прогу, на асме, helloworld, набирал в Hiew'e 6.11 (не такие уж и машкоды), дивясь причудам x86-ой архитектуры

Ну ребята, на Вас всех вариантов не предусмотришь

Цитата AndNot @ 25.02.07, 19:18

Ну ребята, на Вас всех вариантов не предусмотришь

ну "непомню" могбы предусмотреть

И на меня варианта нет. Я asm изучал по журналу "КомпьютерПресс", а первая программа была не "Hello, world", но и не серьёзный проект - оседала резидентом и после запуска NCMAIN.EXE переназначала синий цвет в палитре. Просто на мониторе с градациями серого плохо видно было

Всем спасибо

Цитата adrax @ 03.02.07, 21:44

Я начал постижение ассемблера с вывода простого MessageBox. Под DOS я асмом не увлекался

А жаль. Имеет ли ассемблер большой смысл под Windows, для меня этот вопрос весьма сомнителен.
MessageBox с таким же успехом можно и на Си вызвать, как и создания окон, кнопочек и всего интерфейса вообще.

Цитата

как и создания окон, кнопочек и всего интерфейса вообще.

да можно ваще на скрипте бэйсика *.vbs непомню только как

Цитата old_lamer @ 10.06.07, 17:05

А жаль.

Кодинг под дос дает немало знаний по железу и внутреннему устройству компа, по принципам его работы и взаимодействию перефирии. Это очень сильно облегчает жизнь даже в вин АПИ

Цитата old_lamer @ 10.06.07, 17:05

Имеет ли ассемблер большой смысл под Windows, для меня этот вопрос весьма сомнителен.

А почему бы и нет? На АПИ асм использоать так же легко как и Си, разницы никакой. Но всегда найдется место для оптимизации. Вот виденный мной на днях код(привожу по памяти):

function Alloc(var pBuff: array of Pointer; var hBuff: array of THandle; bufSize, NumBuff: Integer): Boolean;
var
  i: Integer;
begin
  for i := 0 to NumBuff-1 do begin
    hBuff[i] := GlobalAlloc(GMEM_MOVEABLE or GMEM_SHARE or GMEM_ZEROINIT, bufSize);
    if hBuff[i] = 0 then
      begin
        Alloc := FALSE;
        Exit;
      end;
    pBuff[i] := GlobalLock(hBuff[i]);
    if pBuff[i] = nil then
      begin
        Alloc := FALSE;
        Exit;
      end;
  end;
  Alloc := TRUE;
end;

В данном куске возможна утечка памяти, но суть не в этом. Очевидны две вещи. Первое. Необходимо вернуть массив указателей. Второе. Участки памяти блокируются, соответственно нет никакой необходимости в раздельном выделении и блокировке (в самой проге они нигде не разблокируются, только при освобождении памяти). На асме я бы сделал примерно так:

Alloc proc NumBuff: dword, BufSize: dword
  uses ebx, edi
    mov     ebx, NumBuff
    mov     eax, BufSize
    add     eax, 4
    mul     ebx
    invoke  GloballAlloc, GMEM_FIXED or GMEM_ZEROINIT, eax
    .if (eax != NULL)
        push    eax
        mov     edi, eax
        lea     eax, [eax+ebx*4]
        .while (ebx != 0)
            stosd
            add     eax, BufSize
            dec     ebx
        .endw
        pop     eax
    .endif
    ret
Alloc endp

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

Цитата Дьяволица @ 10.06.07, 17:11

да можно ваще на скрипте бэйсика *.vbs непомню только как

Можно Но смысл? Кстати, если вспомнишь - черкни пожалуйста

MsgBox "Hello, World!"

переименовывем в *.vbs и воля ну и так далее только можно с параметрами и многие апи функции

Добавлено 11.06.07, 20:27

Цитата

Можно Но смысл?

ну типа в тему и ответ что зачем тогда в си когда можно ваще так

Цитата Дьяволица @ 11.06.07, 20:26

MsgBox "Hello, World!"
переименовывем в *.vbs и воля

насколько я помню, создать окна и их оконные функции так не получится

Сообщение отредактировано: e-moe - 13.06.07, 05:02

Цитата e-moe @ 13.06.07, 05:01

насколько я помню, создать окна и их оконные функции так не получится

правда ? а я думала можно
а откуда ты это помнишь ?

Программа обслуживания 24-битного измертельного АЦП на atmega8 AVR. Около 560 строк ассемблерного кода.
После этого чо-нить накатать на x86 уже стало не трудно, но как-то обломно и противно - до того ублюдская архитектура, даже не архитектура, а какой-то кривой забор из костылей и подпорок.

Точно так же выражались те, кому пришлось сменить 8080 на х86 Но ко всему можно привыкнуть

Цитата Дьяволица @ 13.06.07, 06:53

правда ? а я думала можно
а откуда ты это помнишь ?

оно просто не дает тебе вызвать CreateWindow...

Я думаю, достаточно висеть этой теме вверху

Я начал с Delphi BASM - так изучил все ring3-инструкции 386, далее таким же образом изучил MMX и немного SSE, асм использую исключительно для оптимизации.
Первая программа именно на чистом ассемблере была, если правильно помню, по копированию дискет из-под DOS.

Цитата antigen @ 13.06.07, 07:24

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

Например?

Цитата ors_archangel @ 06.08.07, 16:23

Например?

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

Цитата cppasm @ 07.08.07, 08:10

Нормальная архитектура - это некоторым людям сохранение обратной совместимости с ранними моделями процессоров очень не нравится...

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

Цитата wind @ 07.08.07, 08:20

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

Возможно это просто вопрос терминов, но я не согласен что это костыли.
Это расширения. Почему сопроцессор как отдельное устройство - это костыль?
У него другие типы данных, другое назначение - потому он и отдельное устройство.
То же самое со всем остальным - SSE, Protected Mode.
А как ты правильно заметил без обратной совместимости он даром никому нужен не будет...

Ну так большинство наворотов вводилось в х86, исключительно для обеспечения работы многозадачных операционок. В тоже время это весьма простой CPU, из числа доступных, cверхмощных вычислительных платформ. Под многие его фичи (Real/Protected/MMX/SSE) очень интересно программить.

Цитата ors_archangel

Я начал с Delphi BASM

До сих пор восхищаюсь BASM, без которого врядли стал бы использовать Delphi.

Цитата wind @ 07.08.07, 08:20

Сопроцессор как отдельное устройство со своим стеком и командами - костыль

Начиная с четверок сопроцессор уже встроенный. Так о каком отдельном устройстве идет речь?

Цитата wind @ 07.08.07, 08:20

защищённый режим - снова костыль

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

Цитата n0p @ 07.08.07, 11:59

До сих пор восхищаюсь BASM

Не представляю, как можно кодить без макросов Да и простой счетчик адреса($) очень облегчает жизнь. Я уж не говорю про невозможность ариф. операций с адресами меток, про отсутствие Size(вот счастье то размеры структур самому высчитывать), да и много чего. В общем BASM тянет на игрушку, не более. Серьезные вещи на нем реализуются через костыли.

А что такое BASM ? Built-in assembler или что ?

Цитата AndNot @ 07.08.07, 17:31

Начиная с четверок сопроцессор уже встроенный. Так о каком отдельном устройстве идет речь?

Я об организации взаимодействия с ним. Логически он остался отдельным устройством.

Цитата wind @ 08.08.07, 04:05

Я об организации взаимодействия с ним. Логически он остался отдельным устройством

Это смотря какую логику прикручивать Логически и блоки работы с памятью (вычисление адреса, load\store буферы, LSU\MOB) можно рассматривать как отдельные устройства, а при желании и целочисленный умножитель тоже А если судить по стадиям обработки микроопераций, то в пеньках обработка FPU\MMX\SSE операций ничем не отличается от других - в P6 это вообще единый конвеер с общим загадочным планировщиком RS, а в NetBurst операции после ROB разделяются на несколько (практически) равноправных потоков (memory, FPU\MMX\SSE, slow-ALU, fast-ALU), направляемых на свои исполнительные блоки, поэтому приписывать FPU какое-то особый статус в такой архитектуре не приходится. А вот в архитектуре AMD операции FPU\MMX\SSE действительно выделяются в отдельный удлинненный конвеер, но связано это не с "тяжким наследием прошлого", а просто соображениями оптимизации (уменьшением длины конвеера и пенальти за непредсказаные переходы для быстрых и более популярных ALU\Mem операций, по сравнению с "медленными" FPU\MMX\SSE) и если бы AMD64 разрабатывался с нуля, то наверняка бы такое разделение сохранилось, т.к. оно логично по своей природе и к "костылям" никакого отношения не имеет

PS: А вот стэковая организация регистров FPU видимо действительно пережиток прошлого и если бы не проблемы совместимости, то вполне можно было бы реализовать прямую адресацию регистров

Цитата AndNot @ 07.08.07, 17:31

Не представляю, как можно кодить без макросов

А я не представляю как можно с макросами
Никогда не пользуюсь, всё руками...
Так что на вкус и цвет...

Цитата leo @ 08.08.07, 03:43

А что такое BASM ? Built-in assembler или что ?

BASM - Borland Assembler.
Они сами так свой встроенный ассемблер назвали, он так в справке значится

Цитата AndNot @ 07.08.07, 17:31

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

А где там трюки если не секрет?
Кроме формата дескрипторов который такой какой есть для совместимости с PMode 286, вроди ничего там такого не наблюдается...
Насчёт VGA - там да, есть немного.
Ну так цели такие были - разработчики адресное пространсво экономили, а не простоту обеспечивали...

Сообщение отредактировано: cppasm - 08.08.07, 07:06

Цитата cppasm @ 08.08.07, 07:04

А где там трюки если не секрет?

А тебе ни о чем не говорит структура дескрипторов? Выглядит, мягко говоря, уродливо. Понимаю, что совместимость, но ведь можно было реализовать совсем по другому, но инженеры предпочли съэкономить, заюзав старый формат. Один бит гранулярности чего стоит Так радиолюбители экономят транзисторы.

Цитата cppasm @ 08.08.07, 07:04

Насчёт VGA - там да, есть немного.

Там очень много. Причем заметь, что бы избавиться от некоторых трюков, разработчики наплевали на совместимость с CGA, Hercules и тд. И правильно сделали.

Цитата AndNot @ 08.08.07, 07:29

Так радиолюбители экономят транзисторы.

А по-моему так они сохраняют совместимость
Иначе на 386 программы рассчитаные на 16-bit PMode просто бы не работали...

Цитата cppasm @ 08.08.07, 08:23

А по-моему так они сохраняют совместимость

В том то и дело, что могли бы сделать по другому, если бы не жмотились

Цитата AndNot @ 07.08.07, 17:31

Я уж не говорю про невозможность ариф. операций с адресами меток, про отсутствие Size(вот счастье то размеры структур самому высчитывать), да и много чего.

Размеры структур высчитывать ни к чему - для этого есть оператор TYPE
Ну а с адресами и метками действительно косяк. С глобальными указателями на функции и переменные - понятно, т.к. это лишние хлопоты при компиляции и линковке dcu. Но не позволять вычислять разность адресов локальных меток, да еще при этом выдавать дебильное сообщение о релоках, которые тут ни к селу ни к городу - это конечно чересчур тупо

Цитата AndNot @ 07.08.07, 17:31

В общем BASM тянет на игрушку, не более

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

Цитата

BASM тянет на игрушку, не более

тока для тех кто не играл в него по крупному Это вещь, причем посерьёзней чем TASM, а отсутствие некоторых фич - так ведь острой необходимости в этом нет, вместо $ вполне достаточно offset'ов на метки. Так же и с мракосами. Всегда их заменял на вызовы функций или, разворачивал. чтоб глаза не мозолили. Один фик, ЯВУ в них не загонишь.

Цитата leo @ 08.08.07, 15:56

А встроенный асм это и есть полезная игрушка - поупражняться в оптимизации

Смотря в какой оптимизации. Если по скорости, то тут будет больщой облом. Ты лучше меня знаешь, как важно, в таких случаях, выравнивание кода и данных. Только вот в ЯВУ этим управлять можно только косвенно, да и то - не везде и не во всех.

Цитата n0p @ 08.08.07, 16:44

а отсутствие некоторых фич - так ведь острой необходимости в этом нет, вместо $ вполне достаточно offset'ов на метки

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

Цитата n0p @ 08.08.07, 16:44

Так же и с мракосами

Это ты загнул По мне запись:

    invoke MessageBox, NULL, _T("Use macro string!"), _T("Helloy"), MB_OK

значительно эстетичнее и нагляднее, нежели:

    push MB_OK
    push offset szTitle
    push offset szMessage
    call MessageBox

Или взять такую задачу, как шифрование. Вот простой пример, когда я использовал эту фичу, от ламеров, которые любят править строки в программе:) :

XORTEXT = 1 ; 0 - при отладке
XORKEY  equ 57h
 
MACRO SETXORTEXT delaytime,msg
ifnb <delaytime>
  if XORTEXTS
    db not(delaytime xor XORKEY)
    else
    db delay
  endif
endif
  IRPC ASS,<msg>
  if XORTEXTS
    db not('&ASS' xor XORKEY)
    else
    db '&ASS'
  endif
  ENDM
ENDM
 
; а затем просто объявляем текстовые данные
        SETXORTEXT       9,<SCREEN SAVER III>
        SETXORTEXT       11,<for>
        SETXORTEXT       9,<DOS Navigator>

Попробуй ка на BASM такое заделать
Подобным макаром реализуется и вычисление CRC имен функций, необходимое при кодинге без таблиц импорта. А на BASM тебе придется вычислять все отдельно. Лишняя трата времени, особенно при переделках.
Или возьми такую больную тему, как появление новых команд процессора. Что прикажешь делать? Менять компилятор? А вот при наличии макросов это уже не проблема. Никто не мешает мне использовать SSE даже с 3-м тасмом.

Цитата n0p @ 08.08.07, 16:44

Один фик, ЯВУ в них не загонишь

Ошибаешься Посмотри на фасм, там все высокоуровневые средства реализованы в виде макросов.
Да и на простом тасме макросы могут реализовать практически все. По крайней мере я реализовывал if/while/case и прочие. Причем вложенные

Цитата

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

Сойдемся на том что есть некая куча г-вна, как правило на 100пудофф абсолютно бесполезного

Цитата

Попробуй ка на BASM такое заделать

Я лутше с BASMA перейду на ЯВУ, и спокойно все на нем сделаю, особо не задалбываясь

Цитата AndNot @ 08.08.07, 19:10

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

Я то как раз знаю, что требование выравнивания кода и данных это перестраховка из разряда "береженого бог бережет", которая в большинстве пратических задач никакой ощутимой роли не играет, за исключением редких, особых случаев ловли блох при супероптимизации тонких циклов. В NetBurst выравнивание кода вообще не важно, т.к. рулит Т-кэш (правда при ловле блох иногда может вылезать зависимость от выравнивания, но это непредсказуемые косяки, требующие особого подхода). В P6 и AMD невыравненные метки циклов могут в худшем случае приводить к дыркам в 1-3 микрооперации в конвеере, что, во-первых, не обязательно приводит к задержке (т.к. может сглаживаться очередью команд), во-вторых, для толстых циклов потеря одного такта особой роли не играет, а тонкие циклы по правилам следует разворачивать. О выравнивании данных и вообще говорить нечего - 4-байтные данные в дельфях всегда выравнены (если самому не накосячить с packed record), а для массива double потеря 1 такта в 4/64 = 1/16 случаях, да с учетом латентностей FPU и побочных факторов - это капля в море.

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

leo, все верно, да не совсем. Для более старых моделей выравнивание более критично. Я уж не говорю про SSE, сам замерял, разбросы были ощутимые ;-)

AndNot SSE предназначен для массовых вычислений, следовательно над динамической памятью, поэтому выравнивание данных - это задача не BASM, а MM (Memory Manager), я так понимаю. Есть, например, FastMM для Delphi7, который, насколько я помню всё специально выделяет по границе 16 байт (используется в движке GLScrene). Хотя, конечно, лишней такая возможность не была бы...

Цитата ors_archangel @ 09.08.07, 11:26

AndNot SSE предназначен для массовых вычислений, следовательно над динамической памятью

Ну статические массивы никто не отменял, другой вопрос что их компилятор HLL выравнивает...

Цитата cppasm @ 09.08.07, 14:15

Ну статические массивы никто не отменял

Однако!.. Я себе так представляю: SSE в аудио приложении, задача - обработка звука, звук - в статическом массиве? SSE в графическом приложении, задача - обработка геометрии, неужели и геом. модели - в статическом массиве... (кстати бывает - в демках, признаю) Мне кажется, что (всё-таки) 99% данных, которые поточно (т.е. массово) обрабатыватся через SSE, где он и имеет смысл - это динамическая память, соотв. от сюда и тезис о том, что задача выравнивания ложиться вследствие всего этого не на HLL-компилятор (или люой другой), а на менеджер памяти, используемый для выделения оной. Если есть контрпримеры, интересно было бы их услышать.

Сообщение отредактировано: ors_archangel - 09.08.07, 23:30

Цитата ors_archangel @ 09.08.07, 23:29

Если есть контрпримеры, интересно было бы их услышать.

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

Сообщение отредактировано: cppasm - 10.08.07, 06:51

Цитата cppasm @ 09.08.07, 14:15

Ну статические массивы никто не отменял, другой вопрос что их компилятор HLL выравнивает...

Другой вопрос - как?

Цитата ors_archangel @ 09.08.07, 23:29

Мне кажется, что (всё-таки) 99% данных, которые поточно (т.е. массово) обрабатыватся через SSE, где он и имеет смысл - это динамическая память

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

Цитата ors_archangel @ 09.08.07, 23:29

задача выравнивания ложиться вследствие всего этого не на HLL-компилятор (или люой другой), а на менеджер памяти, используемый для выделения оной

Хотелось бы еще узнать, как работает GetMem? Может кто рылся в ней?

Цитата AndNot @ 10.08.07, 08:02

Другой вопрос - как?

Ну так это уже от компилятора зависит и в большинстве случаев управляемо...

Цитата AndNot @ 10.08.07, 08:02

GetMem

В Delphi 5-7 по крайней мере MM не плох, а начиная минимум с Delphi9 используется ещё значительно более оптимизированный вариант.

Цитата getmem.inc

cAlign = 4;

Вот такое выравнивание использует стандартный MM Delphi 7.
Вообще, MM различает два вида блоков - большие и маленькие :

Цитата getmem.inc

cSmallSize = 4*1024;

Если size <= cSmallSize, то блок выдаётся из массива smallTab, иначе - выделяется динамически, но, что важно, что все блоки выравниваются только по cAlign, т.е. по dword, плюс перед большими блоками добавляют заголовок (8 байт как я когда-то смотрел, может уже путаю, раньше ещё может 4 было, в Delphi 5, точно не помню). В итоге, если блок больше страницы памяти 4k, то он будет выровнен по 8 байтам, иначе - по 4. При небольшом тестировании получилось, что из 1000 блоков размером от 4097 до 69633 адреса, кратные 16 байтам получили 410 блоков, а остальные 590 получили адреса, кратные только 8 байтам. Малые блоки же, при ещё более простой проверке выдали блоки с адресами, кратными вообще 4 байтам. Теперь берём RecyclerMM из glScene (аналогичный MM используется и BD3, TurboDelphi10 и в остальных Delphi8+ думаю тоже). Как и заявляет разработчик, к блокам не добавляется ни загловков, ни хвостов, и все они выровнены (включая блоки даже самого малого размера - 4 б) строго по 16 байтам, так что динамическую память для SSE в Delфi в принципе выровнять не составляет труда - в свежих версиях Delphi это bydefault, а более мудрые можно легко научить благодаря механизму замены MM. Конечно, статике это не поможет

я сначала ничего не писал, только книжку читал Юрова, разбираясь не в том, КАК сделать, а в том, как это будет работать и почему... а потом уже просто было и hello world сделать
повезло мне короче в этом плане... жаль не так как с ООП

Цитата FFF1 @ 13.08.07, 00:21

КАК сделать, а в том, как это будет работать и почему

Имхо, одно и то же. Если только под "как сделать" не понимать, "как поскорее сделать, лишь бы работало как-нибудь". Имхо, как раз к ассемблеру, особенно в современное время, последнее бессмысленно.

Давно это было. В университете, естественно заставляли . Начинал с мелких, типа Hello World. Но в целом ассемблер сила.

> Если только под "как сделать" не понимать

не не не, я имел ввиду такую ситуацию, к примеру
"Я знаю, что бы вызвать MessageBox, 0, "str1", "str2", 0 надо написать ручками в редакторе invoke, но не знаю почему ИМЕННО от этого покажется месадж бокс и что будет делать процессор в это время, не знаю как ОС создает окно, и т.п."

Между прочим самая большая проблема учеников, студентов - поверхностность изучения очень и ограниченость тем, что обьясняют учителя/преподаватели

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

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

Я кампильнул HelloWorld! - но в голове не осталось ничего... как там проц работал хз

Сообщение отредактировано: semiono - 31.08.07, 04:07