Добрый день! Стоит задача перевести исходную строку в верхний регистр. Ассемблер очень плохо знаю. Код нашла на просторах интернета. Подскажите, пожалуйста, в чем причина неверной работы?

Добрый день! Стоит задача перевести исходную строку в верхний регистр. Ассемблер очень плохо знаю. Код нашла на просторах интернета. Подскажите, пожалуйста, в чем причина неверной работы?

В том, что строка оканчивается 10, а не 0, когда код отрабатывает до символа 0. А вообще, странно, что функция перевода строки в верхний регистр называется _start :) Или это вся программа? Какая ОС (Windows, Linux, DOS (DOSBox))?

В том, что строка оканчивается 10, а не 0, когда код отрабатывает до символа 0. А вообще, странно, что функция перевода строки в верхний регистр называется _start :) Или это вся программа? Какая ОС (Windows, Linux, DOS (DOSBox))?

Вся программа. Linux

32 бита?

Девушка и линукс?

32 бита?

да

Девушка и линукс?

вроде того)

да

Через ret не выходят. Выходят через mov eax,1 xor ebx,ebx int 80h Это если без вывода результата на экран.

Хотя, х/з, может, и ret сработает, я не вот прям линуксоид...

mov eax, 1 ; _exit( mov ebx, 0 ; 0) int 80h такой выход в другой программе делала

mov eax, 4 mov ebx, 1 mov ecx, in_str mov edx, 5 int 80h c выводом результата

вроде того)

От такого ответа у меня аж телега вылетела.

mov eax, 4 mov ebx, 1 mov ecx, in_str mov edx, 5 int 80h c выводом результата

Всё правильно. И выход тоже предыдущее тоже (это эквивалентно тому, что я написал). Только ret надо убрать тогда. А после 10 добавить 0 ('vhod',10,0).

Ну или 0 можно не добавлять, а заменить or al,al на cmp al,10.

спасибо, попробую

Ребят вопрос, есть код программы в одну строку, можно ли автоматом восстановить его структуру?

линтеры

Хотя, х/з, может, и ret сработает, я не вот прям линуксоид...

там crt стдлибовский подтягивается обычно

там crt стдлибовский подтягивается обычно

С чего бы это вдруг? Смотря как и чем компилировать. Если просто: nasm -f elf test.asm -o test.o ld -s test.o -o test ...то никакого crt не будет. Да и без main как crt будет работать?

Кто-нибудь знает, чему равны загадочные значения MAX_HLE_NEST_COUNT и MAX_RTM_NEST_COUNT (уровни вложенности для TSX) или как их узнать программно? В Intel-A SDM вообще об их значениях ничего не сказано, даже MSR таких нет.

Кто-нибудь знает, чему равны загадочные значения MAX_HLE_NEST_COUNT и MAX_RTM_NEST_COUNT (уровни вложенности для TSX) или как их узнать программно? В Intel-A SDM вообще об их значениях ничего не сказано, даже MSR таких нет.

Что это за книга?

☝️

Не понял, как это относится к моему вопросу? 🤔

вот я и спрашиваю, мож опечатался tsx/tss

вот я и спрашиваю, мож опечатался tsx/tss

Нет, не опечатался. Да и я ж конкретно про константы спрашиваю. Там даже в них есть ключевые слова: HLE, RTM :)

Кто-нибудь знает, чему равны загадочные значения MAX_HLE_NEST_COUNT и MAX_RTM_NEST_COUNT (уровни вложенности для TSX) или как их узнать программно? В Intel-A SDM вообще об их значениях ничего не сказано, даже MSR таких нет.

Посмотри в утекших исходниках UEFI могут быть

Посмотри в утекших исходниках UEFI могут быть

Всмысле в «утёкших»? TianoCore есть на гитхабе.

А помимо Тианы есть ещë реализации UEFI, интересно?

А помимо Тианы есть ещë реализации UEFI, интересно?

ТианоКор это полноценная свободная реализация, без блобов. А так есть куча «форков», например, apple использовали свою версию, когда оно было ещё первой ревизии.

Есть Clover, загрузчик Mac OS X на «обычном» железе, имеющий в своём составе модифицированный тиано.

Всмысле в «утёкших»? TianoCore есть на гитхабе.

Это лишь малая часть. Вендоры имеют свои модификации, плюс там кода работающего с самим железом нет, так называемый PI - Platform Initialization

Туда же входит и Intel MRC - Memory Reference Code, там часто можно найти MSR, которых нет в доках

Гуглите AMI leaked UEFI sources

TianoCore потому и опенсурс, потому что там нет ничего по-настоящему интересного

Посмотри в утекших исходниках UEFI могут быть

А какое отношение UEFI может иметь к TSX? Вы точно о том говорите? Это Translational Synchronization Extensions, аппаратная реализация транзакционной памяти для многопоточных программ. Реализуется расширениями HLE (префиксы xacquire, xrelease) и RTM (инструкции xbegin, xend, xabort, xtest). Константы, о которых я спрашиваю — это аппаратные, опять же, ограничения глубины вложенности. Причём тут UEFI ? 🤷‍♂

Вчера тестил HLE дома через SDE (ибо у меня такой фичи нет). Забавно так: меняешь значение мьютекса из потока (скажем, с 0 на 1 через xacquire lock inc [m]), читаешь это значение, там 1. Читаешь из другого потока, он видит его как 0. Т.е. оно меняется только для того потока, который его изменил. Если во втором потоке записать туда 2 (так же через xacquire), третий поток всё равно увидит 0 (а первый 1, второй 2). Мне вот интересно, как это решается для потоков, которые выполняются на одном ядре (без учёта HT даже)? Участвует ли в этом каким-либо образом ОС? И остаются ли мьютексы всегда в кэше (ведь физически они вряд ли записываются в память)? Короче, надо нормально по-RTFM-ить.

Вызов WinAPI внутри блока приводит к аборту из-за «unfriendly instruction» jmp far. Видимо, при переходе в ядро. Короче, надо хорошенько такие вещи профилировать, дабы они не работали неожиданными образом.

А какое отношение UEFI может иметь к TSX? Вы точно о том говорите? Это Translational Synchronization Extensions, аппаратная реализация транзакционной памяти для многопоточных программ. Реализуется расширениями HLE (префиксы xacquire, xrelease) и RTM (инструкции xbegin, xend, xabort, xtest). Константы, о которых я спрашиваю — это аппаратные, опять же, ограничения глубины вложенности. Причём тут UEFI ? 🤷‍♂

Это при том, что это инициализируется каким либо образом при старте железа

Я не сказал что точно там можно встретить, но вполне вероятно

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

Интел половину а то и больше в паблик не выкладывает

Можно погуглить Intel PDF confidential

Можно погуглить Intel PDF confidential

Ок, спс.

https://github.com/aengelke/fadec

Влючение поддержки AVX в real-mode: org 0x100 ; Enable SSE mov eax,cr0 and al,0xFB ; clear coprocessor emulation CR0.EM (bit 2) or al,0x2 ; set coprocessor monitoring CR0.MP (bit 1) mov cr0,eax mov eax,cr4 or eax,0x40600 ; set CR4.OSFXSR (bit 9), CR4.OSXMMEXCPT (bit 10) and CR4.OSXSAVE (bit 18) mov cr4,eax ; Enable AVX xor ecx,ecx xgetbv ; load XCR0 register or al,7 ; set AVX, SSE, x87 bits xsetbv ; save back to XCR0 ; Test SSE xorps xmm0,xmm0 xorps xmm1,xmm1 addss xmm0,xmm1 ; Test AVX vzeroupper vxorps xmm0,xmm0,xmm0 vxorps xmm1,xmm1,xmm1 vaddps xmm2,xmm0,xmm1 ret Запускаю в VMware (MS-DOS). Доходит до vzeroupper и виснет. Что ему ещё не хватает?

Даже добавляю код из Intel SDM для проверки поддержки AVX, выдаёт, что всё ок. mov eax, 1 cpuid and ecx, 018000000H cmp ecx, 018000000H; check both OSXSAVE and AVX feature flags jne not_supported ; processor supports AVX instructions and XGETBV is enabled by OS mov ecx, 0; specify 0 for XCR0 register xgetbv ; result in EDX:EAX and eax, 06H cmp eax, 06H; check OS has enabled both XMM and YMM state support jne not_supported mov eax, 1 jmp done not_supported: mov eax, 0 done:

Инфа взята из https://wiki.osdev.org/SSE

а оно точно могёт в реалмоде?

а оно точно могёт в реалмоде?

А почему не должно?

А почему не должно?

потому что префиксы c4 и c5 это vex и evex они в реалмоде вроде как заняты опкодами les и lds

а префикс 66 работает поэтому и ссе тоже

https://software.intel.com/en-us/forums/intel-isa-extensions/topic/297055 это не читал но из названия понятно

>>Oh, right, I forgot that VEX prefix only works in 16-bit protected mode, not in real mode or V86.

https://software.intel.com/en-us/forums/intel-isa-extensions/topic/297055 это не читал но из названия понятно

Ох, спасибо! Попробую в PMode перейти и там проверить.

потому что префиксы c4 и c5 это vex и evex они в реалмоде вроде как заняты опкодами les и lds

Дизассемблер, к примеру, HIEW однозначно декодирует AVX именно как AVX, а не как LDS, LES и пр. В PMode (не x64) тоже есть LDS и LES.

Всё верно. Заменил or al,0x2 на or al,0x3 и добавил в конец: mov eax,cr0 and al,not 1 mov cr0,eax И всё заработало.

#book Программирование на Ассемблере для PIC Носов

Всё верно. Заменил or al,0x2 на or al,0x3 и добавил в конец: mov eax,cr0 and al,not 1 mov cr0,eax И всё заработало.

Т.е. ты на милисекундочку перешел в пм а потом обратно?

Я бы добавил cli до и sti после.

Т.е. ты на милисекундочку перешел в пм а потом обратно?

Да. Если не менять сегментные регистры, можно даже с памятью работать так же, как в RM :) Про cli/sti — это конечно. Уж не стал сообщение редактировать. А по поводу МИЛЛИсекундочки... Я тут померил скорость переключения RM-PM-RM (т.е. туда и обратно в цикле), у меня под ВМтраврь получилось полмиллиона пар переключений в секунду. Т.е. довольно неплохая скорость. Так что, при жгучем нежелании работать всё время под PM, можно даже приключаться, когда надо, туда-сюда :). Не вот прям красота, но если очень нннадо, то можно.

Для чистоты эксперимента (замера скорости) можно разбавить переключения ещё каким-то кодом. И замерить ещё в чистом DOS'е и на AMD, ибо дело было на Intel.

Ага, прикольно.

Это чо сессия что ли

Это чо сессия что ли

они хоть не пишут, а у меня уже 3е с однотипными заданиями

и асм у них для K580bm80

Это чо сессия что ли

Угу.

Охренеть. Тут уже почти 900 человек))

Ага-ага.

В соседнем чате (@pro_osdev) возник вопрос о том, уместно ли здесь (в @proasm) говорить про разработку драйверов. Хорошо бы зафиксировать где-то в описании, является ли данный чат обсуждением низкоуровневых вещей, а не только асма. @AlexFails одобрил эту идею. Дело за малым — это как-то обозначить. По сути, просто в описание можно добавить строку типа "Чат об ассемблере, реверсе и низкоуровневом программировании в целом." Давайте сделаем, у кого есть права на это.

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

В соседнем чате (@pro_osdev) возник вопрос о том, уместно ли здесь (в @proasm) говорить про разработку драйверов. Хорошо бы зафиксировать где-то в описании, является ли данный чат обсуждением низкоуровневых вещей, а не только асма. @AlexFails одобрил эту идею. Дело за малым — это как-то обозначить. По сути, просто в описание можно добавить строку типа "Чат об ассемблере, реверсе и низкоуровневом программировании в целом." Давайте сделаем, у кого есть права на это.

Не согласен

Или даже поменять заголовок на pro.asm (low-level, re).

Не согласен

+

@AlexFails

только асм и ничего кроме асма

Предлагаю название pro.lowlevel

Не согласен

Ок, а где эти вопросы тогда обсуждать? Других чатов нет.

Предлагаю название pro.lowlevel

Новый создать, в смысле?

Ок, а где эти вопросы тогда обсуждать? Других чатов нет.

Я не согласен с длинным именем группы.