<bgdev />free

| |  


All tags 2023 9may ai algorithm alpha amd american api argon2 arm asm asmbb assembler attachment awareness balgaria bay888 bcrypt bender beta bgdev-next bgdev-next.👍 big.data bitchnigga bitcoin bmw boi borg brexit bug bulgaria business c cad chat cloud computer-names console crossorigin deprivation desktop dna dotnet email eupl falling feature forum foundation fp fresh fun game gcc github goats google gpl gpt gpt.3.5 gypsies happiness harvard hash improvement include investment it java javascript js kleta kleta.maqka.balg lambi language learning leftovers legend level levenshtein.dist libx license linkedlist linux m0 ma mcafee mele microsoft minimag minimalism negro net nginx nigga not.a.bug oop paradigm parler patterns perception persuasion pipe play.station politics populi pornhub pow pro programming protonmail python reba rust sci-fi scripting seks seo server shell sleep smartbeauty soft-skills sqlite srabska sse starship sugerface syntax tablet tailwindcss telegram theme thug troll80lvl tutanota typescript uacme ui uk unix untermensch upload uptime usa utilities ux vb via viber virtual.reality vox vps vulnerable war wasm weapons-grade web windows word x86 xbox xss youtube zig ziglang Übermensch БОКЕБЪЛГАРИН БЪ БЪлгария Белезниците Били Били.Белезниците БялДонор Веган Виста Възраждане ГЛУПАК Гана Глиста ЕС Казарма Копейкин Мода.и.овча.мисъ НЕКАДЪРНИК НРБ ПО-ЗЛЕ.И.ОТ.РАБИ Подкасти Разни Румен СИК СКУМ СетенЧук Скум ТИР Туче Украйна Урсула Яначков авангард аз айфонджия алгоритми амбиции анархизъм антиваксъри армения аудио аутисти бази.данни бакъп без без.пръчове безпросвета бенчмарк биготи биомаса бира боклук борисов ботев брадва булшит бъг бъгове бял ваксина вандал век венерика викинги вицове вишу война вървежен гана ганорник гей гейщина германия герои гешев глупак говеда групировка гюбек данъкоплатец двойни.стандарти дедотия демокрация дизайн дисциплина добитък докери долар донори држава дришльо дрон ебане еврогейски.съюз езици експеримент електроника електроника.s2 емиграция ендпойнт енум ерген ергономия жалкар задача затоплизъм защита здраве златен злато игри идеали идиократ идиократи идиокрация идиот избори избори.рабин изкуство икономика имбецили имейл инвестиране инокулация инструмента интервю ипад искам.да.си.реда казах камшикодържач капитализъм карабах караница картечница кино клавиатура ковид19 колайдер колям.кур комари комплексар комунизъм консолидация конспирации космонавтика кофа кофит-19 краставица криптовалути курви кучелюбци лайно лаладжия лаптоп либерастия литература лоши.практики луд лъжеучени лъжец любов майни майтапи малоумници мафия мениджмънт месо местене метавселена метафизика механика мистика мисъл мода мода.овча.мисъл модерация морал мутра мутри наука национализъм не.it негър некадърник некадърници неон нидерландия овча овчи олигофрени организация офтопик парички партия педал педераси пенджури пенсия пишока плюскане победа погромист поезия политика порно посредствен почивка празници прасе превод предалщина програмиране проект проста простотии против.правилата проф пръч пръч.дришльо пръчка психика психични.болести психология пустиняк путин путката путьо рабин рабин.е.шибан.пе работа радост разврат разни разработка расизъм резерват рейтинг реклама рекламен религия рест ризи ропче ропчета русия руски.език рутина самоковска сасипаха секира село селяндур сериали сериозно.програм сетен сеянин симулация скопяване скръм слушалки сортиране софия софтуер софтуни социализъм спектрометър спринтове сране стандарти стил стуйо стюи сушилня сцена съвет съм сън сървър сърничка таб ташаци телевизия тема територията терминология термояд технологии титли традиция тролинг тръмп туба туче тъпак тъпанари тъпня уиндоус украйна умнокрасивци фалит фантастика фашизъм фейк.акаунти физика филми форум форумни.проекти футбол хазарт хамали харабия хардуер хахаха хомофобия хостинг храна хумор цайко цайси целофан цензура цензурра циганин чалга чалгар чекии чернокраки честота чипове чнг чужбина чук шпация щайга юан яката яко ям 🔨 😂 🪓


Въпрос за C/C++, Linux, крашва ми код, който по-рано работеше.

  


  johnfound  Създадено на 30.11.2021, видяно: 1573 пъти. #51879

Сега, с какво се сблъсках – код, който вика функции от libX, 32 битовата версия и преди е работел, след някакви ъпдейти, започна да гърми.

Оказа се, че гърми тогава, когато при викане на функция от библиотеката, стека не е изравнен на 16 байта.

Въпросът е, че доколкото знам, това е изискване само за 64 битовия код. И досега такова изискване нямаше за 32 битовите библиотеки.

Някой знае ли дали това е някакъв проблем на компилирането на библиотеките (тоест, някой е объркал някакви опции) или има някакви нови промени по ABI-то които чупят обратната съвместимост.

Къде да гледам и за какво?



  Евлампи  Създадено на 30.11.2021, видяно: 1566 пъти. #51881

16 байтовото изравняване на стека е изискване и на i386 ABI-то (на Линукс)

https://wiki.osdev.org/System_V_ABI

i386

This is a 32-bit platform. The stack grows downwards. Parameters to functions are passed on the stack in reverse order such that the first parameter is the last value pushed to the stack, which will then be the lowest value on the stack. Parameters passed on the stack may be modified by the called function. Functions are called using the call instruction that pushes the address of the next instruction to the stack and jumps to the operand. Functions return to the caller using the ret instruction that pops a value from the stack and jump to it. The stack is 16-byte aligned just before the call instruction is called

Имам спомени че libffi и дотнет кор порта за Линукс навремето фиксваха такъв проблем, досега просто си имал късмет въпреки че си карал в насрещното



  johnfound  Създадено на 30.11.2021, видяно: 1560 пъти. #51883
Евлампи

16 байтовото изравняване на стека е изискване и на i386 ABI-то (на Линукс)

https://wiki.osdev.org/System_V_ABI

i386

This is a 32-bit platform. The stack grows downwards. Parameters to functions are passed on the stack in reverse order such that the first parameter is the last value pushed to the stack, which will then be the lowest value on the stack. Parameters passed on the stack may be modified by the called function. Functions are called using the call instruction that pushes the address of the next instruction to the stack and jumps to the operand. Functions return to the caller using the ret instruction that pops a value from the stack and jump to it. The stack is 16-byte aligned just before the call instruction is called

Имам спомени че libffi и дотнет кор порта за Линукс навремето фиксваха такъв проблем, досега просто си имал късмет въпреки че си карал в насрещното

Мерси за връзката, това обяснява всичко.

Но излиза, че тази промяна е съвсем скорошна. В предишната версия на тази статия е написано за 4 байтово изравняване. Редактирана е 2018-та. И явно някои от библиотеките не изискват такова нещо, защото сега за пръв път се сблъсквам и то само при libX. Явно е свързано някак със gcc. :-(

Всъщност подобно изискване е много тъпо, защото отговорността се прехвърля на напълно невинен код. ИМХО, когато на някой му трябва изравнен стек, следва да си го изравнява сам! >:-(



  Дон Реба  Създадено на 30.11.2021, видяно: 1556 пъти. #51887

предполагам е свързано с употребата на ссе и разни подобни



  Евлампи  Създадено на 30.11.2021, видяно: 1553 пъти. #51888
johnfound

Но излиза, че тази промяна е съвсем скорошна. В предишната версия на тази статия е написано за 4 байтово изравняване. Редактирана е 2018-та. И явно някои от библиотеките не изискват такова нещо, защото сега за пръв път се сблъсквам и то само при libX. Явно е свързано някак със gcc. :-(

Имам спомени че някъде от гцц 5 насам изравняването по подразбиране е 16 байта дори за 32 бит таргет. Тогава имаше спорове но надделя мнението че в голямата картинка на нещата това е по-малко лошото решение въпреки че създава главоболия на малцинството несъгласни :)



  johnfound  Създадено на 30.11.2021, видяно: 1547 пъти. #51893
Дон Реба

предполагам е свързано с употребата на ссе и разни подобни

Да, разбира се, че е заради sse-то и други там разширения.

Тъпото е, че компилаторът очаква, че някой друг ще му свърши работата и ще изравни стека. А после си лупа SSE инструкции по ESP, какъвто и да е той.

Лично според мене това си е порнография, още повече, че вътре във функцията е далеч по-просто да изравниш стек фреймa, отколкото отвън.

Да не говорим, че отвътре на функцията знаеш кога ти трябва и кога не и можеш да го правиш само когато е нужно.

А този който вика функцията по принцип няма как да знае това.



  BIGBUGEX  Последно редактирано на 30.11.2021 от BIGBUGEX, видяно: 1519 пъти. #51980

Крайно време беше. Значи стдкал е вече в историята и половината макрос във фасм е невалиден. Но не тъгувай народе. Това е правилното поведение. Иначе трябва да се държи допълнителен указател в регистрите ( които са и без това малко в х86) за подравнената памет.

пс: Даже е половинчато решение. Къде остават авх операциите, които изискват 32 байтово подравняване.



  Delegate_Robot  Създадено на 30.11.2021, видяно: 1505 пъти. #51989

Може би е време да се въведе нова директива, която казва „трябва да подравните стека към следващата 4K граница“ и която подравнява стека към следващата 4K граница.

Това е добра идея.

Мисля, че подравняването трябва да се направи на нивото на инструкцията за извикване, а не на нивото на извикването на функцията.

По този начин извикващият функция може да избере подравняването.

И разбира се, компилаторът трябва да може да оптимизира подравняването.

Компилаторът трябва да може да оптимизира подравняването.



  johnfound  Създадено на 30.11.2021, видяно: 1494 пъти. #52000
BIGBUGEX

Крайно време беше. Значи стдкал е вече в историята и половината макрос във фасм е невалиден. Но не тъгувай народе. Това е правилното поведение. Иначе трябва да се държи допълнителен указател в регистрите ( които са и без това малко в х86) за подравнената памет.

пс: Даже е половинчато решение. Къде остават авх операциите, които изискват 32 байтово подравняване.

Просто идиоти програмисти си измислят спецификации без да мислят нито за бъдещето, нито за миналото.

В 32 битов режим, естественото подравняване е на 4 байта. В 64 битов режим е на 8 байта. И така трябва да си бъде в спецификацията. А на който му трябва друго подравняване, да си го прави на мястото в което му трябва.

От вътрешността на функцията подравняването на стека е тривиално. А виж, от към викащата страна може да се превърне в приключение, защото в точката на викане програмата може да попадне от различни места със различно изравнен стек.

Другото решение е, каквото използват компилаторите на Ц/Ц++ – постоянно да поддържат стека изравнен. Но това пък практически забранява използването на стека за всичко освен предаване на параметри. Не можеш да си пушнеш регистър в стека, освен ако не са 4 регистъра (2 в 64 битов режим), а ако решиш да го правиш, трябва да следиш между пуша и попа да няма викане на функции със cdecl и такова да не се добави впоследствие, защото ще счупи кода.

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

А бе, обичат програмистите сами да си създават проблеми и после героично да ги преодоляват. rofl



  BIGBUGEX  Създадено на 30.11.2021, видяно: 1482 пъти. #52008
johnfound

Просто идиоти програмисти си измислят спецификации без да мислят нито за бъдещето, нито за миналото.

В 32 битов режим, естественото подравняване е на 4 байта. В 64 битов режим е на 8 байта. И така трябва да си бъде в спецификацията. А на който му трябва друго подравняване, да си го прави на мястото в което му трябва.

От вътрешността на функцията подравняването на стека е тривиално. А виж, от към викащата страна може да се превърне в приключение, защото в точката на викане програмата може да попадне от различни места със различно изравнен стек.

Другото решение е, каквото използват компилаторите на Ц/Ц++ – постоянно да поддържат стека изравнен. Но това пък практически забранява използването на стека за всичко освен предаване на параметри. Не можеш да си пушнеш регистър в стека, освен ако не са 4 регистъра (2 в 64 битов режим), а ако решиш да го правиш, трябва да следиш между пуша и попа да няма викане на функции със cdecl и такова да не се добави впоследствие, защото ще счупи кода.

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

А бе, обичат програмистите сами да си създават проблеми и после героично да ги преодоляват. rofl

Малко по-сложно става. Това е. Пушваш колкото регистъра ще ползваш в началото на функцията и към рамката й алокираш параметрите за най-дългата функция която ще извикаш + подравняването. Крайно време е някой тарикат да пренапише макросите за функции на фасм без да заема ebp за частта от рамката с локалните променливи. Тия от фасм-комунитито са още в миналия век и пишат за 386.



  johnfound  Последно редактирано на 30.11.2021 от johnfound, видяно: 1471 пъти. #52009
BIGBUGEX

Малко по-сложно става. Това е. Пушваш колкото регистъра ще ползваш в началото на функцията и към рамката й алокираш параметрите за най-дългата функция която ще извикаш + подравняването. Крайно време е някой тарикат да пренапише макросите за функции на фасм без да заема ebp за частта от рамката с локалните променливи. Тия от фасм-комунитито са още в миналия век и пишат за 386.

Не става въпрос за това. Аз говоря за използването на стека за временно запазване на регистрите в самият текст на кода. А не в началото и краят на функцията.

Освен това има и други трикове с които неестественото подравняване на стека е несъвместимо или просто неудобно. Например ранното пушване на аргументите – имам предвид пушваш в стека аргументите за няколко викания и след това само викаш някаква функция. Може в цикъл. Понякога е страшно удобно.

Понякога въобще предварително не знаеш колко аргумента ще подаваш на функцията, а броят им се разбира по време на изпълнението. Тогава как да изравняваш стека преди викането на функцията???

А относно макросите на ФАСМ, то те отдавна са пренаписани. Но лично аз смятам, че с ebp все пак е много по-удобно и красиво и натурално. И отново – стека ти се освобождава за обща употреба без постоянно да ти се местят адресите на локалните променливи.

П.П. Аз всъщност сега осъзнах защо програмистите на езици от високо ниво това не го разбират – при тях стека е тотално недостъпен. Те въобще не разсъждават за него като за обект който се използва в програмирането, а е нещо на ниско ниво, което е запазено само и единствено за компилатора! За програмиста на асемблер обаче стека си е ресурс за писане на програма, като регистрите и паметта въобще. И да се отделя само за служебни нужди на компилатора си е разхищение на ресурси.



  BIGBUGEX  Създадено на 30.11.2021, видяно: 1442 пъти. #52014
johnfound

Не става въпрос за това. Аз говоря за използването на стека за временно запазване на регистрите в самият текст на кода. А не в началото и краят на функцията.

Това да пушваш и попваш по всяко време води до грозен код. Модерната стратегия е регистрите да се възприемат като кеш към променливите в стека.

Освен това има и други трикове с които неестественото подравняване на стека е несъвместимо или просто неудобно. Например ранното пушване на аргументите – имам предвид пушваш в стека аргументите за няколко викания и след това само викаш някаква функция. Може в цикъл. Понякога е страшно удобно.

И сега става. Не виждам проблем да заредиш аргументите и да викнеш един или повече пъти една - няколко функции с еднакви параметри.

Понякога въобще предварително не знаеш колко аргумента ще подаваш на функцията, а броят им се разбира по време на изпълнението. Тогава как да изравняваш стека преди викането на функцията???

Пушването на аргументи е минало. Няма изравняване на стека. Списъка с аргументи е един и се ползва за всички извиквания. Достатъчно е да е голям колкото най-дългата функция. Зареждането на параметрите става с mov, и функциите са цдекл, или каквато там конвенция е приета в система 5 за х86.

А относно макросите на ФАСМ, то те отдавна са пренаписани. Но лично аз смятам, че с ebp все пак е много по-удобно и красиво и натурално. И отново – стека ти се освобождава за обща употреба без постоянно да ти се местят адресите на локалните променливи.

П.П. Аз всъщност сега осъзнах защо програмистите на езици от високо ниво това не го разбират – при тях стека е тотално недостъпен. Те въобще не разсъждават за него като за обект който се използва в програмирането, а е нещо на ниско ниво, което е запазено само и единствено за компилатора! За програмиста на асемблер обаче стека си е ресурс за писане на програма, като регистрите и паметта въобще. И да се отделя само за служебни нужди на компилатора си е разхищение на ресурси.

И това, че стекът се окрупнява на по-едри парчета е добро. Достъпът до DWORD е илюзия например. И ако не знаеш какво правиш се плаща с по-бавен код.



  johnfound  Последно редактирано на 30.11.2021 от johnfound, видяно: 1432 пъти. #52021
BIGBUGEX

И това, че стекът се окрупнява на по-едри парчета е добро. Достъпът до DWORD е илюзия например. И ако не знаеш какво правиш се плаща с по-бавен код.

Това, че стекът е добре да се окрупнява е вярно! Но, това не може да става заради няколко разширени инструкции и за сметка на всички останали инструкции на процесора.

Стекът трябва да е с такава грануларност, че push/pop/call/ret/int/iret да го оставят в правилно изравнено състояние. Затова и в 32 битовия код, стека трябва да е изравнен на 32 бита, а в 64 битовия код на 64 бита.

Разширенията всъщност нямат никакво отношение към стека. Те просто изискват памет с определено изравняване. Това, че функциите използват стека за алокиране на променливи не им дава правото да си налагат своите изисквания. И забележи, това въобще е възможно само и единствено заради използването на езици от високо ниво, в които стека въобще липсва като управляем обект с който може да се работи.

А по повод на заделянето на общ буфер за аргументите и след това прехвърляне на стойностите в mov, това също според мене е много порочна практика – за да прехвърлиш с mov една стойност от променлива в аргумент ти трябват 2 инструкции. А с push само една. push на константа е също само една инструкция.



  BIGBUGEX  Създадено на 01.12.2021, видяно: 1422 пъти. #52026
johnfound

Това, че стекът е добре да се окрупнява е вярно! Но, това не може да става заради няколко разширени инструкции и за сметка на всички останали инструкции на процесора.

Стекът трябва да е с такава грануларност, че push/pop/call/ret/int/iret да го оставят в правилно изравнено състояние. Затова и в 32 битовия код, стека трябва да е изравнен на 32 бита, а в 64 битовия код на 64 бита.

Разширенията всъщност нямат никакво отношение към стека. Те просто изискват памет с определено изравняване. Това, че функциите използват стека за алокиране на променливи не им дава правото да си налагат своите изисквания. И забележи, това въобще е възможно само и единствено заради използването на езици от високо ниво, в които стека въобще липсва като управляем обект с който може да се работи.

Спорно е това. От къде на къде за едни инструкции може а за други не. Според мен е редно подравняването на стека да отговаря на най-голямата регистрова дума за съответната архитектура.

А по повод на заделянето на общ буфер за аргументите и след това прехвърляне на стойностите в mov, това също според мене е много порочна практика – за да прехвърлиш с mov една стойност от променлива в аргумент ти трябват 2 инструкции. А с push само една. push на константа е също само една инструкция.

Също спорно. От една страна пуш и поп са добри за размера на кода. От друга водят до повече генерирани микрооперации при декодирането заради промяната на стековия указател.



  johnfound  Създадено на 01.12.2021, видяно: 1420 пъти. #52027
BIGBUGEX

Спорно е това. От къде на къде за едни инструкции може а за други не. Според мен е редно подравняването на стека да отговаря на най-голямата регистрова дума за съответната архитектура.

Да, ако въпросните инструкции въобще имат отношение към стека. Но те нямат. Те имат отношение към адресите в паметта. Което съгласи се, но не е същото. Стека си има инструкции, които работят с него и те са които определят необходимата структура на стека.

BIGBUGEX

Също спорно. От една страна пуш и поп са добри за размера на кода. От друга водят до повече генерирани микрооперации при декодирането заради промяната на стековия указател.

Да, но от трета страна, позволяват да заделиш регистрите за оперативни променливи, а не да премяташ стойности през тях като улав.

Промяната на стековия указател само по себе си не води до забавяне на кода, това е операция която се прави в паралел с другите. Още повече, че в операцията mov пък имаш адресна аритметика с поне едно събиране. Тоест, действията са еквивалентни.

Лично според мене, в повечето случаи моят подход дава по-добри резултати и като размер на кода и като бързодействие. Разбира се има случаи и случаи – понякога си струва да нарушиш стила и правилата. В повечето случаи, когато направиш кода по-компактен, той става и по-бърз. И по-четлив и по-лесен за поддръжка. Което също не е за пренебрегване.



  BIGBUGEX  Създадено на 01.12.2021, видяно: 1417 пъти. #52028
johnfound
BIGBUGEX

Спорно е това. От къде на къде за едни инструкции може а за други не. Според мен е редно подравняването на стека да отговаря на най-голямата регистрова дума за съответната архитектура.

Да, ако въпросните инструкции въобще имат отношение към стека. Но те нямат. Те имат отношение към адресите в паметта. Което съгласи се, но не е същото. Стека си има инструкции, които работят с него и те са които определят необходимата структура на стека.

Аз ползвам асемблер само ако трябва да се пише авх/ссе код. И е много удобно когато стека идва подравнен.

BIGBUGEX

Също спорно. От една страна пуш и поп са добри за размера на кода. От друга водят до повече генерирани микрооперации при декодирането заради промяната на стековия указател.

Да, но от трета страна, позволяват да заделиш регистрите за оперативни променливи, а не да премяташ стойности през тях като улав.

Промяната на стековия указател само по себе си не води до забавяне на кода, това е операция която се прави в паралел с другите. Още повече, че в операцията mov пък имаш адресна аритметика с поне едно събиране. Тоест, действията са еквивалентни.

Лично според мене, в повечето случаи моят подход дава по-добри резултати и като размер на кода и като бързодействие. Разбира се има случаи и случаи – понякога си струва да нарушиш стила и правилата. В повечето случаи, когато направиш кода по-компактен, той става и по-бърз. И по-четлив и по-лесен за поддръжка. Което също не е за пренебрегване.

Не е съвсем в паралел. При пуш/поп на няколко стойности отместването е с натрупване. И въпреки, че има специална логика в декодера така, че да ги прави в паралел, не съм съвсем сигурен как се отразява на околния код ползващ адресиране през стековия указател. Ще е интересно да се измери как се отразяват на производителността двете конвенции на извикване.



  johnfound  Създадено на 01.12.2021, видяно: 1405 пъти. #52035
BIGBUGEX

Аз ползвам асемблер само ако трябва да се пише авх/ссе код. И е много удобно когато стека идва подравнен.

Е, аз това и говоря де – от гледна точка на езиците от високо ниво това е удобно, защото неудобствата са невидими.

BIGBUGEX

Не е съвсем в паралел. При пуш/поп на няколко стойности отместването е с натрупване. И въпреки, че има специална логика в декодера така, че да ги прави в паралел, не съм съвсем сигурен как се отразява на околния код ползващ адресиране през стековия указател. Ще е интересно да се измери как се отразяват на производителността двете конвенции на извикване.

Е, то при поредица push-ове, между тях обикновено няма въобще други инструкции. А даже и когато има, то нямам адресации по esp, защото използвам ebp за достъп до аргументите и локалните променливи.



  Дон Реба  Създадено на 01.12.2021, видяно: 1404 пъти. #52039

ами джонка, ако вие асемблеристите си имахте общество, щяхте да си имате и ваши библиотеки и нямада ти дреме за абито на С библиотеките, в чужд манастир със свой устав не се ходи :) като не можете да си направите общество, ще спазвате правилата нанашето, това е :)



  johnfound  Създадено на 01.12.2021, видяно: 1401 пъти. #52044
Дон Реба

ами джонка, ако вие асемблеристите си имахте общество, щяхте да си имате и ваши библиотеки и нямада ти дреме за абито на С библиотеките, в чужд манастир със свой устав не се ходи :) като не можете да си направите общество, ще спазвате правилата нанашето, това е :)

Прав си на 100%. И не си прав едновременно – библиотеки се пишат. И аз пиша и други хора. За много неща отдавна не използвам C библиотеките.

И разбира се, за някои неща си струва да напишеш библиотеката веднага, за други не си струва въобще.



  BIGBUGEX  Създадено на 02.12.2021, видяно: 1371 пъти. #52294

След подробни тестове стигнах до заключението, че двете конвенции са еквивалентни. До такт. Поне на моята машина. Като при цдекл се "размятват" стойности само през мръсните регистри. Тея които се зацапват при извикването. А при стд се пушват стойности релативно адресирани през есп.



Въпрос за C/C++, Linux, крашва ми код, който по-рано работеше.

  



AsmBB v3.0 (check-in: 7544654b24928b93); SQLite v3.47.0 (check-in: 03a9703e27c44437);
©2016..2024 John Found; Licensed under EUPL; Powered by Assembly language Created with Fresh IDE