Auto-relocação - Self-relocation
Na programação de computador, um programa de auto-relocação é um programa que realoca suas próprias instruções e dados dependentes de endereço quando executado e, portanto, é capaz de ser carregado na memória em qualquer endereço. Em muitos casos, o código de auto-relocação também é uma forma de código de auto-modificação .
Visão geral
A auto-relocação é semelhante ao processo de realocação empregado pelo linker - loader quando um programa é copiado do armazenamento externo para a memória principal; a diferença é que é o próprio programa carregado, e não o carregador no sistema operacional ou shell, que realiza a realocação.
Uma forma de auto-relocação ocorre quando um programa copia o código de suas instruções de uma sequência de locais para outra sequência de locais dentro da memória principal de um único computador e, em seguida, transfere o controle do processador das instruções encontradas nos locais de origem da memória com as instruções encontradas nos locais de destino da memória. Como tal, os dados operados pelo algoritmo do programa são a sequência de bytes que definem o programa.
A auto-relocação normalmente acontece no tempo de carregamento (depois que o sistema operacional carregou o software e passou o controle para ele, mas ainda antes de sua inicialização terminar), às vezes também ao alterar a configuração do programa em um estágio posterior durante o tempo de execução .
Exemplos
Carregadores de inicialização
Como exemplo, a auto-relocação é frequentemente empregada nos estágios iniciais de sistemas operacionais de inicialização em arquiteturas como IBM PC compatíveis , onde carregadores de inicialização de cadeia de nível inferior (como o registro mestre de inicialização (MBR), registro de inicialização de volume (VBR) e inicial estágios de inicialização de sistemas operacionais como DOS ) movem-se para fora do lugar para carregar o próximo estágio na memória.
Drivers x86 DOS
No DOS , a auto-realocação às vezes também é usada por drivers mais avançados e RSXs / TSRs carregando-se "alto" na memória superior de forma mais eficaz do que possível para carregadores "altos" fornecidos externamente (como LOADHIGH / HILOAD , INSTALLHIGH / HIINSTALL ou DEVICEHIGH / HIDEVICE etc. desde DOS 5) para maximizar a memória disponível para aplicativos. Isso se deve ao fato de que o sistema operacional não tem conhecimento do funcionamento interno de um driver a ser carregado e, portanto, tem que carregá-lo em uma área de memória livre grande o suficiente para conter todo o driver como um bloco, incluindo seu código de inicialização, mesmo se isso for liberado após a inicialização. Para TSRs, o sistema operacional também precisa alocar um Prefixo de segmento de programa (PSP) e um segmento de ambiente . Isso pode fazer com que o driver não seja carregado na área de memória livre mais adequada ou até mesmo impedir que seja carregado muito alto. Em contraste com isso, um driver de auto-relocação pode ser carregado em qualquer lugar (incluindo na memória convencional ) e, em seguida, realocar apenas sua parte residente (normalmente muito menor) em uma área de memória livre adequada na memória superior. Além disso, os TSRs de auto-relocação avançados (mesmo se já carregados na memória superior pelo sistema operacional) podem ser realocados sobre a maior parte de seu próprio segmento PSP e buffer de linha de comando e liberar seu segmento de ambiente para reduzir ainda mais a pegada de memória resultante e evitar fragmentação . Alguns TSRs com relocação automática também podem alterar dinamicamente sua "natureza" e se transformar em drivers de dispositivo, mesmo se carregados originalmente como TSRs, normalmente também liberando alguma memória. Finalmente, é tecnicamente impossível para um carregador externo realocar os drivers na memória expandida (EMS), na área de alta memória (HMA) ou na memória estendida (via DPMS ou CLOAKING ), porque esses métodos requerem pequenos stubs específicos do driver para permanecer no convencional ou memória superior para coordenar o acesso à área de destino de realocação e, no caso de drivers de dispositivo, também porque o cabeçalho do driver deve permanecer sempre no primeiro megabyte. Para conseguir isso, os drivers devem ser especialmente projetados para suportar a auto-relocação nessas áreas.
Alguns drivers DOS avançados também contêm um driver de dispositivo (que seria carregado em deslocamento + 0000h pelo sistema operacional) e TSR (carregado em deslocamento + 0100h) compartilhando uma parte de código comum internamente como binário fat . Se o código compartilhado não for projetado para ser independente da posição , ele requer alguma forma de correção de endereço interno semelhante ao que, de outra forma, já teria sido executado por um carregador de realocação ; isso é semelhante ao estágio de correção da auto-relocação, mas com o código já sendo carregado no local de destino pelo carregador do sistema operacional (em vez de ser feito pelo próprio driver).
Programas IBM DOS / 360 e OS / 360
O IBM DOS / 360 não tinha a capacidade de realocar programas durante o carregamento. Às vezes, várias versões de um programa eram mantidas, cada uma construída para um endereço de carregamento diferente ( partição ). Uma classe especial de programas, chamada de programas de auto-relocação, foi codificada para se realocar após o carregamento. IBM OS / 360 realocou programas executáveis quando eles foram carregados na memória. Foi necessária apenas uma cópia do programa, mas uma vez carregado, o programa não pôde ser movido (o chamado código independente de posição único ).
Outros exemplos
Como um exemplo extremo de auto-relocação (muitas vezes), é possível construir um programa de computador de forma que ele não permaneça em um endereço fixo na memória, mesmo durante a execução. O Apple Worm é um auto-realocador dinâmico.
Veja também
- Eliminação de código morto dinâmico
- RPLOADER - uma API DR-DOS para auxiliar o código de inicialização remota / rede a se realocar enquanto o DOS é inicializado
- Coleta de lixo
- Autorreplicação
- Autorreferência
- Quine (computação)
Notas
Referências
Leitura adicional
- Kildall, Gary Arlen (fevereiro de 1978). "Uma técnica simples para realocação estática de código de máquina absoluto" . Dr. Dobb's Journal of Computer Calisthenics & Orthodontia . People's Computer Company . 3 (2): 10–13 (66–69). ISBN 0-8104-5490-4. # 22. Arquivado do original em 09/09/2017 . Recuperado em 19/08/2017 . [2] [3] [4] (Este método de "redimensionamento", denominado relocação de limite de página , pode ser aplicado estaticamente a uma imagem de disco CP / M-80 usando MOVCPM para maximizar o TPA para programas a serem executados. foi também utilizado de forma dinâmica pelo CP / M depurador dinâmico Ferramenta de depuração (DDT) a deslocar-se na memória superior. a mesma abordagem foi desenvolvida de forma independente por Bruce Van Natta de IMS Associates para produzir posição regulável PL / M código. Como parágrafo deslocalização limite outra variante deste método foi posteriormente utilizado por TSRs auto- relocáveis de HMA dinamicamente como KEYB , SHARE e NLSFUNC sob DR DOS 6.0 e superior. Um método de realocação de deslocamento granular de nível de byte muito mais sofisticado com base em uma abordagem um tanto semelhante foi concebido de forma independente e implementado por Matthias R. Paul e Axel C. Frinke por sua eliminação de código morto dinâmico para minimizar dinamicamente a pegada de tempo de execução de drivers residentes e TSRs (como FreeKEYB).
-
Huitt, Robert; Eubanks, Gordon ; Rolander, Thomas "Tom" Alan ; Leis, David; Michel, Howard E .; Halla, Brian; Wharton, John Harrison ; Berg, Brian; Su, Weilian; Kildall, Scott ; Kampe, Bill (25/04/2014). Laws, David (ed.). "Legado de Gary Kildall: The CP / M IEEE Milestone Dedication" (PDF) (transcrição de vídeo). Pacific Grove, Califórnia, EUA: Computer History Museum . Número de referência do CHM: X7170.2014. Arquivado (PDF) do original em 27/12/2014 . Recuperado em 2020-01-19 .
[…] Leis: […] “ relocação dinâmica ” do SO. Você pode nos dizer o que é e por que foi importante? [...] Eubanks : [...] o que Gary fez [...] foi [...] incompreensível. [...] Lembro-me do dia na escola em que ele entrou pulando no laboratório e disse: Já descobri como me mudar . Ele aproveitou o fato de que o único byte sempre seria o byte de ordem superior . E então ele criou um bitmap . [...] não importava quanta memória o computador tivesse, o sistema operacional sempre poderia ser movido para a memória alta. Portanto, você poderia comercializar isso [...] em máquinas de diferentes quantidades de memória. [...] você não poderia estar vendendo um CP / M de 64K e um CP / M de 47K. Seria simplesmente ridículo ter uma compilação difícil nos endereços. Então Gary descobriu isso uma noite, provavelmente no meio da noite pensando em alguma coisa de codificação, e isso realmente tornou o CP / M possível comercializar. Eu realmente acho que sem essa realocação, teria sido um problema muito difícil. Para fazer as pessoas comprá-lo, pareceria complicado para elas e, se você adicionasse mais memória, teria que comprar um sistema operacional diferente. [...] Intel [...] teve os bytes invertidos , certo, para os endereços de memória. Mas eles estavam sempre no mesmo lugar, então você poderia realocá-lo em um limite de 256 bytes , para ser mais preciso. Você pode, portanto, sempre realocá-lo com apenas um bitmap de onde essas [...] Leis: Certamente, a explicação mais eloquente que já tive de realocação dinâmica [...]
[5] [6] (33 páginas) - Mitchell, Bridger (julho-agosto de 1988). Carlson, Art (ed.). "Z3PLUS & Relocation - Informações sobre ZCPR3PLUS e como escrever o código Z80 de auto-relocação" . The Computer Journal (TCJ) - Programação, Suporte ao usuário, Aplicativos . CP / M avançado. Columbia Falls, Montana, EUA (33): 9–15. ISSN 0748-9331 . arca: / 13960 / t36121780 . Obtido em 2020-02-09 . [7] [8]
- Sage, Jay (setembro-outubro de 1988). Carlson, Art (ed.). "ZCPR3 Corner - Mais sobre código realocável, arquivos PRL, ZCPR34 e programas Tipo 4" . The Computer Journal (TCJ) - Programação, Suporte ao usuário, Aplicativos . CP / M avançado. Columbia Falls, Montana, EUA (34): 20-25. ISSN 0748-9331 . ark: / 13960 / t0ks7pc39 . Obtido em 2020-02-09 . [9] [10]
- Harrell III, John B. (outubro de 1983). "DOSPLUS 3.5" . 80 Micro . Análise. 1001001, Inc. (45): 160, 162, 164-168, 170. ISSN 0744-7868 . arca: / 13960 / t8z906r42 . Obtido em 2020-02-06 . [11] [12]
- Smith, Lee; Haines, Lionel (02/02/1989) [14/08/1987]. RISC OS Application Image Format (anteriormente Arthur Image Format) (Technical Memorandum) (1.00 ed.). Cambridge, Reino Unido: Acorn Computers Limited , Programming Languages Group. PLG-AIF. Arquivado do original em 30/08/2017 . Recuperado em 30/08/2017 .
- Propriedades do formato de imagem ARM . 1993. Arquivado do original em 31/08/2017 . Recuperado em 31/08/2017 .
- Huck, Alex (14/08/2016). "Nachladbare Treiber unter CP / M - PRL2COM" . Homecomputer DDR (em alemão). Arquivado do original em 2020-02-21 . Obtido em 2020-02-21 ; Pohlers, Volker (2017-04-24) [2012-02-20, 2009, 2002, 1988-07-26, 1987-10-11]. "PRL2COM" . Homecomputer DDR (em alemão). Arquivado do original em 2020-02-21 . Obtido em 2020-02-21 .