- 1
- 2
- 3
- 4
void print_line(char *s){
for(int i = 0; i < strlen(s); i++) putchar(s[i]);
putchar('\n');
}
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
0
void print_line(char *s){
for(int i = 0; i < strlen(s); i++) putchar(s[i]);
putchar('\n');
}
Почему C работает медленнее чем JavaScript ?
Цикл for в Си не кэширует условия (в отличие от Паскаля, например, где границы индекса определяются один раз), поэтому будет вызывать strlen на каждой итерации.
Итого сложность получится O(n²).
Вот такой вариант быстрее:
ага, чтобы потом в консоли работало, а в псевдотерминале нет
я ляпнул чуш
все хуже
вызов прерывания будет обработан ОСом и к биосу не попадет unless такой дикий ABI не реализован
так что код сукабляди может и не работаьть
Но именно это и позволяет досовскую программу запустить в окне (если бы это было не так, она бы пачкала своим выводом окна).
А даже если бы и вызвал, то в регистр сегментов надо загрузить адрес такой структуры где сказано что это сегмент 16битного кода, иначе процессор не сможет выполнить код биоса, ну тупо может быть invalid opcode.
А судя по "asm (" и "movw " (AT&T syntax) речь идет о каком-то unix-like.
Так что режим там сто пудово защищенный 32х битный.
Может быть это Xenix: там 16бит, но все равно защищенный (просто без виртуальной памяти)
Кста, в линуксе можно сипать в видемемори напрямую, иксы так делают без DRI.
думаю что там сисколь другой
А BSD срёт на всех и перекомпилирует весь софт для каждой новой версии
Теперь норм.
a(4) это EAX = 0x04 это sys_write
b(1) это EBX = 0x1 это fd = 1 (stdout)
ECX и EDX это буфер и размер соответственно
А теперь скажи мне, почему ты не сделал честно mov в эти регистры?
Разве это не было ли бы это более царски?
а как сделать мув, кста?
movb $4, %eax сработает?
> movb $4, %eax сработает?
Ты хочешь в 32-битный регистр положить 8-битное число? Серьёзно? Или пиши movd, чтобы кокококонстанта была 32-битной, или используй movs/movz, расширяющие число (но они умеют расширять только в два раза: 8 бит до 16, 16 до 32, 32 до 64 и так далее).
Можно, кокококонечно, написать movb $4, %al и получить в трёх старших октетах мусор.
ой я дурак-дурак, конечно я хотел movd это же дабл ворд на интеле.
А можно положидь туда нуль а потом положить в нижнюю половинку (al), но это конечно говнецо
хих, прикольно, я давно на асме не писал
• movl $, %eax займёт 5 байт.
• xor eax, eax + mov al, 4 (пишу в синтаксисе «Интела») займёт 2 + 2 = 4 байта (ещё и во флаги насрёт).
• lea eax, [4] займёт 6 байт (когда в квадратных скобках смещение без регистра, нужна 32-битная константа).
• Можно исхитриться и написать lea eax, [eax + 4], тогда она займёт 3 байта (смещение может быть 8-битным или 32-битным), но нужно обнулить eax (самый короткий способ сделать это займёт 2 байта). Итого xor eax, eax + lea eax, [eax + 4] займут 5 байт.
• Погуглил про movsx и movzx (давно ими не пользовался). Оказывается, можно 8 бит расширить сразу до 32, но работают они только с регистрами или с памятью.
Тогда mov al, 4 + movzx eax, ax займут 2 + 2 = 4 байта.
mov al, 4 + cbw + cwde займут 4 байта.
Сначала эти мелкие инструкции засрут декодер, а потом ещё и выстроятся в очередь друг за другом.
проверь
WSL тоже не будет
Лососисис тунцов
Real x86-64 Linux may or may not handle int 0x80 even in 64-bit process. That depends CONFIG_IA32_EMULATION of kernel config.
WSL is not.
https://github.com/Microsoft/WSL/issues/3107
верно?
все пересобрано
Пойду у себя на слаке отключу его и пересоберу ядро и проверю
в ядре там разумеется есть CONFIG_IA32_EMULATION.
Но весь юзерленд собран конечно уже с x64.
Почему я так думаю?
Да потому что под WSL есть убунта. То-есть юзерленд убунты работает в системе где вместо Linux -- эмуляция его сисколов виндовым процессом (lxss или как оно там)
Эта эмуляция не умеет INT 0x80, о чем написан выше. Но убунта как-то там работает.
Это намекает на отсутствие в убунтячем узерленде 32битного кода с INT. И это логично, ведь весь код там собирается из сырцов и ничто не мешает его перебрать
У меня от дебага виндового «Heaven's Gate» до сих пор ночные кошмары.
Запускается обработчик прервания, копирует к себе нужные данные и выполняет код
но наверное ей это не важно если оно знает что SYSCALL всегда x64 а INT и SYSENTER всегда x32 (??)
Могу ли я запустить проприетраный софт 1999го года на CentOS 7?
Я не могу найти ссыл чото, зато нашел ссыл с точностью до наоборот!
ABI для модулей у линукса как раз не стабильно: моудли надо перебирать для каждого ядра.
И вот Icaza пишет что дескать вот из этой нестабильности и мы нестабильны тоже и просрали битву за десктоп
Неужели даже просто до O(n) с неважно какой константой оптимизация не доводит?
там размер страки палучить это O(1)
и по этому я за "Pascal"
"Pascal": O(1). "C": O(n).
2. Кэширование границ итератора цикла "for".
"Pascal": есть. "C": нет, цикл реализован как обычный while.
Фу, середина - это всё ещё та же трудоёмкость. Квадратичное говно!
В оптимизированных версиях putchar '\0' ставят сразу в самое начало, и for (... strlen ...) даёт O(1), когда питушарское кэширование длины - O(n).
Почему квадратичное? N×log(N)
И правда, Си предоставляет кучу способов прострелить себе колено.
А ты юзай её правильно и всё будет норм.
Многие олдскульные функции из сишной либы тоже и на глобалки завязаны и строки портят.
Ниже петху про break написал.
https://govnokod.ru/4300#comment547526
без хвостовой рекурсии этот питух порвет себе стек, и замолчит
а с хвостовой он может срать до бесконечности
эй, питу: не забывай цитировать свое предыдущее сообщение
Адрес знает драйвер nvidia:
Driver "nvidia"
http://us.download.nvidia.com/solaris/1.0-9755/README/chapter-02.html
–— А можно перепрограммировать контроллер 13-го прерывания?
Друг пытается понять, чего же от него хотят и что это за загадочный контроллер. Выдохнув, отвечает:
—– Ну, допустим, можно. А тебе это зачем нужно?
–— Винт отформатировать хочу! На низком уровне!
Вот на флопаре он работал, но можно было и без биоса обойтись: обычный format.com это делал (и высокоуровневое и низкоуровневое), иначе как бы им можно было сменить размер дискеты?
В BIOS'ах конца 90-х была функция «Low Level Format», но на самом деле это была файка: она фактически тупо записывала нули во все логические блоки, т. е. это высокоуровневое форматирование, но без файловой системы.
На флопаре format.com выполнял не совсем низкоуровневое форматирование. Он не мог отформатировать сбойные дискеты или дискеты, которые до этого были неправильно отформатированы.
Настоящее низкоуровневое форматирование дискет выполняла программа «FDA» –— «floppy drive analyzer». Она умела читать межсекторные промежутки, записывать любые заголовки физических секторов. С помощью неё можно было отформатировать дискету не только для «IBM PC», но и для «ДВК», «Агата» –— вот этого всего зоопарка чудовищ. Вот эта программа могла творить чудеса.
Представим себе физическую цепочку MFM или Floppy.
[ISA]-->[контроллер]-->[диск]
Контроллер принимает некоторые команды от софта (драйвера или утилиты или софта в INT 13h).
Диск сам по себе это просто блин (или блины). Контроллер разбивает его на блоки: тупо пишет на дорожке границы блока. И сам потом по этим границам ориентируется.
Это и есть "Low Level Format".
Контоллер может принимать от софта команды для этой самой разметки. Это есть у контроллера флопарей или у контроллера MFM.
Именно это делает INT 13h AX=05h . В зависимости от плотности этих границ можно получать разную плотность дискет.
-----------------
Теперь цепочка IDE/ATA:
[PCI]-->[IDE Контроллер]-->Протокол_IDE-->[Контроллер_диска+сам_диск]
IDE Контроллер (его еще называют HBA -- HostBasedController) принимает от софта команды для навигации по диску (CHS или LBA, не важно). В этих коммандах размер блока равен 512
Переводит их в термины IDE/ATA и шлет контроллеру, встроенному в диск (у которого uart для терминала и муха цэцэ).
Контроллер_диска КАК ТО выполняет их на диске. Что там внутри -- похуй. Там может быть черти ябутся, и нету никаких блоков вообще. Важно что принимает он их в терминах 512-байтовых блоков ("блочное устройство", как говорят юниксоиды).
Сам диск разбит на КАКИЕ ТО блоки на заводе. Об этом знает его контроллер.
Так что проводить Low Level Format у него нельзя: не получится. Именно потому INT 13h лукавит.
Но это всё еще Low Level Format. Потому что он говорит: "У меня три блина, сто дорожек и размер блока 512 байт".
---------------
Логическим (high level) форматированием я называю процесс создания ФАЙЛОВОЙ СИСТЕМЫ на диске посредством драйвера файловой системы.
Он создает кластера (которые могут быть больше блоков) и их таблицы (MFT, FAT итд).
Согласен?
Судя по каким баграм от иногда возникающей потери данных, так оно и есть.
А что останется от нас? Дискеты уже сгнили, например.
Именно потому я за глиняные таблички
Потому что Шлёма Маляр
http://wiki.c2.com/?ShlemielThePainter