Confabulações aleatórias sobre ponteiros "huge" no x86 (para os assembleiros)

8 views
Skip to first unread message

Juan Castro

unread,
Mar 10, 2015, 3:43:47 PM3/10/15
to Lista PC-Old, Retrocomputação BR, gd...@googlegroups.com
Nos compiladores C de modo real (ou seja, que funcionavam em XT), você
podia "mais ou menos, mais ou menos" abstrair a segmentação de
ponteiros usando o modelo "huge". Em qualquer operação de ponteiros
(incrementar, decrementar, somar, subtrair, indexar, referenciar uma
variável) ele fazia uma pré-normalização para que o offset sempre
estivesse emtre 0 e 15 (0x0F), e uma pós-normalização antes de
retornar um ponteiro como resultado. Se não me falha a memória, você
também podia declarar arrays maiores que 64k, tipo "unsigned long
numerosarodo[50000];".

Uma maneira alternativa seria manter o endereço de segmento sempre
como 0x?000 e deixar o offset flutuar entre 0 e 0xFFFF, mas da maneira
usada resultam ponteiros sempre bons pra usar em REP MOVSB da vida com
tamanhos ate 64 KB - 16, então realmente é a melhor opção.

Aí me bateu: a aritmética necessária para manter os ponteiros
normalizados come ciclos de máquina que é uma beleza. Se eu voltasse
no tempo antes do 80286 existir (de preferência antes mesmo do 8086
existir) e fosse sugerir opcodes à Intel, eu sugeriria instruções do
tipo:

ADDFP <segreg>:<offreg>,<constante>
ADDFP <segreg>:<offreg>,<registrador>
SUBFP <segreg>:<offreg>,<constante>
SUBFP <segreg>:<offreg>,<registrador>
NORMFP <segreg>:<offreg>

Tipo assim: se ES é 0x40D1 e DI é 0x8A19...

"NORMFP ES:DI" faz ES = 0x4972 e DI = 0x0009
"ADDFP ES:DI,1" faz ES = 0x4972 e DI = 0x000A
"ADDFP ES:DI,100h" faz ES = 0x4982 e DI = 0x0009

Etc.

Ah, e lógico, eu também imploraria desesperadamente pra ser possível
chavear o 286 de modo protegido pra real sem precisar estuprá-lo, mas
essa é outra história.

Juan Castro
Enviado do meu Olivetti Programma 101

PopolonY2k

unread,
Mar 11, 2015, 12:58:42 AM3/11/15
to gd...@googlegroups.com
Eu quase...

...não precisei usar o modelo huge, utilizei apenas uma vez quando
modelo "far" não conseguia mais utilizar nada abaixo dos 640Kb.

Isso porque eu estava usando o "pesado" Turbo Vision em um projeto em
C++. Para quem não sabe o Turbo Vision é uma biblioteca de user
interface presente nos compiladores Turbo C++ 3.1 e Turbo Pascal 6.0 e
superiores, inclusive utilizada para fazer a IDE desses compiladores.

O Turbo Vision já estava preparado para operar também no modelo huge e
usar memória acima dos 640Kb, devendo apenas para isso mudar o modelo
de memória no seu projeto e recompilar tudo.

O modelo "far" foi de longe o que mais usei, entretanto qualquer
apontamento direto devia ser feito seguindo o modelo se
segemento/deslocamento dos x86 [SEG:OFFS]. Fiz muito programa para
acessar a memória de vídeo do PC diretamente, mudar atributos de texto
e outras coisas que eram legais na época.

Senão me engano acho que ainda tenho uma biblioteca que imitava as
funções do Clipper para manipulação de tela, só que feita em C ou C++.
Os programas ficavam bonitos quando eu usava essas funções.

Tinha também o modelo de endereçamento "near" que basicamente permitia
apenas enxergar 64kb de uma vez....acho que existia mais para deixar
as coisas parecidas com arquiteturas pré-x86 que só acessavam 64Kb.

[]'s
PopolonY2k
> --
> Você está recebendo esta mensagem porque se inscreveu no grupo "Grupo de desenvolvimento de software e coisas legais para MSX e afins" dos Grupos do Google.
> Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para gdmsx+un...@googlegroups.com.
> Para obter mais opções, acesse https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages