Sempre topo com essa questão em foruns e mídias como o Discord: Como usar funções da biblioteca padrão de C em códigos puramente escritos em assembly? É “fácil”, mas eu não recomendo. Primeiro mostrarei como, usando o NASM e o GCC e depois digo o por quê da não recomendação. Eis um “hello, world” simples:
; test.asm ; Compile com: ; nasm -felf64 -o test.o test.asm bits 64 ; A glibc exige "RIP relative addressing". ; De qualquer maneira, isso é sempre uma boa ; prática no modo x86-64. default rel section .rodata msg: db `hello, world`,0 section .text ; Este símbolo está na glibc! extern puts global main main: ; Chama puts(), passando o ponteiro da string. lea rdi,[msg] call puts wrt ..plt ; return 0; xor eax,eax ret
O código acima é diretamente equivalente a:
#include <stdio.h>
int main( void )
{
puts( "hello, world" );
return 0;
}
Para compilar, linkar e testar:
$ nasm -felf64 -o test.o test.asm $ gcc -o test test.o $ ./test hello, world
Simples assim. O gcc deve ser usado como linker porque ele sabe onde a libc está.
O wrt ..plt é um operador do NASM chamado With Referece To. Ele diz que o símbolo está localizado em uma section específica. No caso a section ..plt, que contém os saltos para as funções da libc (late binding). Isso é necessário, senão obterá um erro de linkagem porque o linker não encontrará o símbolo… PLT é a sigla de “Procedure Linkage Table“. É uma tabela com ponteiros para as funções carregadas dinamicamente da libc.
Eis o porque de minha não recomendação: O compilador nem sempre usa o nome “oficial” da função, que pode ser um #define num header e, ás vezes, existem argumentos adicionais “invisíveis” para certas funções “intrínsecas”, mas o principal argumento contra essa prática é que seu código não ficará menor ou mais rápido só porque você está usando assembly. Por exemplo, ambos os códigos em C e Assembly, acima, fazem exatamente a mesma coisa e têm o mesmíssimo tamanho final (6 KiB, extirpando os códigos de debbugging e stack protection, no caso de C).
De fato, é provável que você crie um código em assembly pior do que o compilador C criaria…
Addedum: Não recomendo, particularmente, que se tente escrever códigos em assembly que usem a libc no ambiente Windows. O problema é que Windows coloca algum código adicional nas funções. Por exemplo, A pilha deve ser alterada para acomodar SEH (Structured Exception Handling), no caso de main, é necessário chamar uma função chamada _main… Coisas assim são problemáticas para o novato.
(4×4, 8×8, 16×16 ou, no caso do h265, outros tamanhos múltiplos de 
. Aqui temos o formato HD (1280×720), Full HD (1920×1080) e 4K (3840×2160). Vale notar que o formato 4K tem o dobro do tamanho (vertical e horizontal) do formato Full HD. Outra nota interessante é que ele não é, necessariamente “4K” (4 mil), mas tem 3840 pixels horizontais! Se bem que esses formatos geralmente são medidos pela quantidade de linhas, não de colunas. Seria esperado que o formato 4K fosse referenciado como 2.16K! :)
, bem próximo do padrão letterbox de aspecto 
. Por quê 486 linhas? No formato NTSC temos dois quadros entrelaçados de 262.5 linhas, ou 525 linhas por quadro completo, mas apenas 486 são visíveis, as 39 linhas “invisíveis” são usadas no pulso de retraço vertical… No entanto, existem formatos europeus (um deles usado no Brasil também): PAL-M e SECAM. O formato PAL-M usa as mesmas 525 linhas, mas tem 480 visíveis, resultando no formato 720×480 com um aspecto de 
. É um aspecto um pouco mais “largo” (wide) que o letterbox. O padrão SECAM tem mais linhas que o NTSC-M e PAL-M (625 linhas), mas, até onde sei, não é mais usado.
e IMAX usa os aspectos de 
ou 
, dependendo do filme. Isso não significa que não existam outros aspectos em uso. Filmes chamados de “35 mm” costumam ter aspecto de 
; Enquanto “70 mm” usam 
; TVs antigas e alguns monitores tinham aspecto de 
; Alguns distribuidores de filmes usam o aspecto de 
para facilitar o escalonamento para os aspectos widescreen e letterbox; Alguns monitores atuais têm aspecto de 
; O padrão norte-americano para a telona de cinema costuma seguir o aspecto de 
… É um pesadelo, não? Não tenho como citar todas os “padrões” existentes porque simplesmente não tenho a acesso a todos eles. Não citei, por exemplo, o usado em “Super 8 mm” (popular nos primórdios, especialmente pela distribuição de filmes pornográficos nesse formato!).
, ou 
, como “widescreen”. Note que a comparação (em is_wide()) é feita usando cálculo inteiro, não ponto flutuante:
fps (ou 29.97 fps), ou seja, padrão NTSC. Com isso, segundo minha “formuletinha”, que mostrei 
fps, ou 23.976 fps. Isso nos dá um bit rate, para 1280×720, de 1.599 Mb/s… Esses cerca de 400 kb/s a menos nos dá uma redução de cerca de duas vezes o tamanho do stream de vídeo. Se, usando minha “formuletinha” eu conseguia uma redução de 4 a 6 vezes do tamanho do stream, agora tenho uma redução de 6 a 8 vezes!
Bit is Myth 
Você precisa fazer login para comentar.