https://ssl.opennet.dev/openforum/vsluhforumID3/116774.html Состоялся (https://mirage.io/blog/announcing-mirage-35-release) релиз операционной системы MirageOS 3.5 (https://mirage.io), позволяющая формировать операционные системы одного приложения, в которых приложение поставляется как самодостаточный "unikernel", способный выполняться без применения операционных систем, отдельного ядра ОС и каких-либо прослоек. Для разработки приложений применяется язык OCaml. Код проекта распространяется (https://github.com/mirage/mirage) под свободной лицензией ISC.<br><br><br>Вся низкоуровневая функциональность, свойственная операционной системе, реализована в форме библиотеки, прикрепляемой к приложению. Приложение может быть разработано в любой ОС, после чего компилируется в специализированное ядро (концепция unikernel (http://queue.acm.org/detail.cfm?id=2566628)), которое может запускаться напрямую поверх гипервизоров Xen, KVM, BHyve и VMM (OpenBSD), поверх мобильных платформ, в форме процесса в POSIX-совместимом окружении или в облачных окружениях Amazon Elastic Compute Cloud и Goo https://ssl.opennet.dev/openforum/vsluhforumID3/116774.html#49 Tue, 12 Mar 2019 03:51:16 GMT &gt;&gt; размером 512 байт <br>&gt; Неа, см: <br>&gt;&gt;&gt; 2 passes, 56 bytes <br><br>Сами по себе эти 56 байт разве запустятся? Всё одно, требуется некий аналог "executable format".<br><br>&gt;[оверквотинг удален]<br>&gt; use16 <br>&gt; mov dx, msg <br>&gt; mov ah, 09h <br>&gt; int 21h <br>&gt; int 20h <br>&gt; msg db 'Hello World!',0Ah,'$' <br>&gt; % fasm hello.asm <br>&gt; flat assembler version 1.73.09 (16384 kilobytes memory) <br>&gt; 2 passes, [b] 23 bytes. [/b] <br><br>Интересно, сколько выйдет подобное на каком-нибудь Sinclair BASIC, где PRINT занимает 1 байт, плюс 2 байта на номер строки, наверное, ещё что-то.<br><br>&gt; Изначально речь шла о (грубом и ориентировочном) размере в довольно узких рамках <br>&gt; ;) <br>&gt; см.<br>&gt;&gt;&gt; компилируется в 113 килобайт, в отличие от мегабайтов Хаскеля <br><br>Ну так то да, килобайты ныне "мало". :)<br><br>&gt; На самом деле тут еще желательно знать, что там линкуется статистически, а <br>&gt; что динамически, т.к. тот же HelloWorld на Си при "gcc -static <br>&gt; -s" запросто может выдать бинарник на 500КБ c гаком, а для <br>&gt; плюсов и на все полтора, но те кто обсуждают, ско https://ssl.opennet.dev/openforum/vsluhforumID3/116774.html#48 Mon, 11 Mar 2019 14:07:38 GMT &gt; размером 512 байт <br><br>Неа, см:<br>&gt;&gt; 2 passes, 56 bytes<br><br>Специально считерил, "срезав" (см. последние три строчки - ";" в интел-синтаксисе комментарий) конец и дав подходящую команду для записи с помощью dd.<br>В принципе, можно и сам код еще (существенно) сделать меньше, но тогда оно может резко стать "qemu-only".<br>Но даже при размере в 512 байт оно выигрывает по размеру общих зависимостей (ни ld-elf, ни ядра не нужно) :P<br><br>Кстати, могу еще предложить:<br>[code]<br> cat hello.asm <br>org 100h<br>use16<br><br>mov dx, msg<br>mov ah, 09h<br>int 21h<br><br>int 20h<br>msg db 'Hello World!',0Ah,'$'<br><br> % fasm hello.asm <br>flat assembler version 1.73.09 (16384 kilobytes memory)<br>2 passes, [b] 23 bytes. [/b]<br>[/code]<br><br><br>&gt; (на некотором железе не запустится), <br><br>Оно ж уже и не модно, давно. Тем более и на "том" железе была куча проблем и проблемок (а так же костылей, костыликов и подпорочек -- достаточно откопать LILO или глянуть (возможно, в старый вариант) GRUB).<br>Хотя з https://ssl.opennet.dev/openforum/vsluhforumID3/116774.html#47 Mon, 11 Mar 2019 13:05:23 GMT Это же MBR размером 512 байт (на некотором железе не запустится), а было "Smallest x86 ELF Hello World" (50 байт + файловый заголовок).<br> https://ssl.opennet.dev/openforum/vsluhforumID3/116774.html#46 Sun, 10 Mar 2019 19:05:14 GMT &gt; 142 многовато, вот 128 <br><br>ЖЫрнота, особенно по зависимостям!<br>[code]<br>% cat real_hello_world.asm<br>BASE equ 07c00h<br>VIDEO_MEM equ 0b800h<br>COLOR equ 02h * 100h<br><br>org BASE<br>use16<br><br>jmp 0:start<br>start:<br><br>cli <br>cld<br>xor ax,ax<br>mov ds,ax<br>sti <br><br>;*******************************<br>;set video out=80x25, 16 colors, page 0<br>;*******************************<br>mov ax,3<br>int 10h<br><br>mov ax, 500h ;0 page<br>int 10h<br><br>mov ax, VIDEO_MEM<br>mov es, ax<br><br>xor di, di<br>mov si, msg<br>mov ax, COLOR<br>mov cx, msg.len<br><br>print:<br> lodsb<br> stosw<br> loop print<br><br>cli<br>hlt<br><br>msg db "Hello World!"<br>msg.len = $ - msg<br>;db BASE+510-$ dup(0)<br>;signature:<br>;dw 0aa55h<br><br>% fasm real_hello_world.asm<br>flat assembler version 1.73.09 (16384 kilobytes memory)<br>2 passes, 56 bytes<br><br>% dd if=/dev/zero count=454 conv=notrunc seek=56 bs=1 of=real_hello_world.bin<br>% echo -n "\0x55\xaa" &gt;&gt; real_hello_world.bin<br>[/CODE] <br>У меня длиннее (или что именно меряли последние два замера?) :) ?<br><br> https://ssl.opennet.dev/openforum/vsluhforumID3/116774.html#45 Sun, 10 Mar 2019 16:26:58 GMT &gt; но рассчитывать на эту особенность опасно, т.к. в будущем может измениться".<br><br>Ну я бы не стал рассчитывать на такие тонкости, с учётом тех серьёзных изменений в stdlib, которые произошли между 3 и 4. С другой стороны, то руководство вообще для дремучей версии 2.<br><br> https://ssl.opennet.dev/openforum/vsluhforumID3/116774.html#44 Sun, 10 Mar 2019 13:23:08 GMT Если там перепутали порядок вычисления аргументов в существующих имплементациях, это одно. Другое дело, что кроме того там написано "порядок не определён; так получилось, что аргументы вычисляются так-то, но рассчитывать на эту особенность опасно, т.к. в будущем может измениться".<br> https://ssl.opennet.dev/openforum/vsluhforumID3/116774.html#43 Sun, 10 Mar 2019 11:47:38 GMT Ну там лажа написана - надо поменять. Простейшая проверка показывает, что right to left:<br><br># let f x y = (x, y);;<br>val f : 'a -&gt; 'b -&gt; 'a * 'b = &lt;fun&gt;<br># f (print_string "Left") (print_string "Right");;<br>RightLeft- : unit * unit = ((), ())<br><br>Понятно, что чем больше у компилятора возможностей, тем больше может быть степень оптимизации. Но сейчас всё согласовано - right to left.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/116774.html#42 Sun, 10 Mar 2019 11:23:33 GMT 142 многовато, вот 128<br>[CODE]<br>$ cat hello.asm <br><br>; fasm demonstration of writing simple ELF executable<br><br>format ELF executable 3<br>entry start<br><br>segment readable executable<br><br>start:<br><br> mov eax,4<br> mov ebx,1<br> mov ecx,msg<br> mov edx,msg_size<br> int 0x80<br><br> mov eax,1<br> xor ebx,ebx<br> int 0x80<br><br>;segment readable writeable<br><br>msg db 'Hello world!',0xA<br>msg_size = $-msg<br><br><br>$ fasm hello.asm <br>flat assembler version 1.73.06 (16384 kilobytes memory)<br>2 passes, 128 bytes.<br><br><br>$ ./hello<br>Hello world!<br>[/CODE]<br> https://ssl.opennet.dev/openforum/vsluhforumID3/116774.html#41 Sun, 10 Mar 2019 11:12:00 GMT Благодарю. Однако, там же сказано (со ссылкой на Драгонбук), что преимущество может дать неопределённый порядок вычисления аргументов, принятый в C.<br><br>In Objective CAML, the order of evaluation of arguments is not specified. As it happens, today all implementations of Objective CAML evaluate arguments from left to right. All the same, making use of this implementation feature could turn out to be dangerous if future versions of the language modify the implementation.<br>http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora029.html<br>