Teixeira
(usa Linux Mint)
Enviado em 25/11/2013 - 21:57h
Quanto à linguagem de máquina, só era necessário conhecer os códigos das instruções em hexadecimal na hora de analisar um "dump" de memória (uma listagem enorme produzida quando ocorria algum erro durante a execução de um programa). Mas essa tarefa era facilitada porque todo mundo que fazia curso de "Assembler IBM" ganhava uma cartela resumo que, entre outras coisas, trazia o mnemônico e o hexadecimal dos códigos de operação de todas as instruções.
Bons tempos aqueles...
Minha experiência com a LM foi algo meio repentino e mais-ou-menos traumático:
É que eu comecei programando minicomputadores Burroughs (atual Unisys) das séries L/TC/AE.
Aí passava um tempão "munhecando" o código, porém na hora de passar para a máquina, tinha de chamar o técnico (a peso de ouro), esperar ele desbloquear o firmware, para então carregar o programa assembler, digitar o meu código, e fazer os primeiros testes.
Ora, um programa em Assembly dificilmente fica 100% na primeira tentativa, especialmente se o programador é iniciante.
Gente, vocês não sabem o que é provocar um loop infinito
em Assembly: É infinito
mesmo, já que não dá para desligar a máquina pelos meios convencionais!
Dependia mais uma vez do técnico, que continuava $endo remunerado por $ua pre$ença.
Depois de tudo pronto, ele bloqueava novamente o firmare, fazendo com que, de toda a memória de 16kB (é isso mesmo: 16 quiloBytes), ficárremos apenas com 512 "palavras de memória", o que evidentemente correspondia a meio quiloByte.
Era tudo o que a gente tinha para fazer folha de pagamento + faturamento +
controle de estoque + contabilidade e mais os extras que sempre apareciam.
Aí, por motivos de ordem econômico-finan$$eira, eu comecei a seguir o exemplo de outros programadores mais experientes:
Escrevia o programa em Assembly como manda o figurino (por causa dos labels), e eu mesmo supria, baseado em uma tabela, o código em Linguagem de Máquina.
De posse do tal código em LM, bastava modificar as posições de memória, sem preci$ar chamar o técnico.
Saía cada instrução esquisita, tipo "A1A1", "B0B0", "CACA" "C0C0", "DAD0", "F0DA", "F0F0", etc, já sabendo que se trata de "zeros", e não da letra "O".
A listagem Assembly segue o código hexadecimal, portanto se expressa através dos algarismos de 0 a 9 e dos caracteres alfabéticos de A até F.
E aí está o macete: A memória era listada em hexadecimal. portanto eu colocava as instruções no endereço que
eu queria.
Programadores Assembly costumavam "esconder o leite" fazendo em seus programas uma série interminável de subrotinas, para dificultar o seu entendimento por parte de terceiros.
No Assembly L/TC/AE a instrução para desviar o fluxo para outra posição de memória era
BRU ("branch unconditional", ou "salto incondicional").
O interessante é que um programa enorme, do tipo Folha de Pagamento, ou faturamento com emissão de nota fiscal e duplicatas (a firma era uma Sociedade Anônima) gerava um rolo de fita perfurada de mais ou menos 6 a 8cm de diâmetro, fora os cartões perfurados (ou edge cards) que continham os dados dos clientes, produtos, transportadores, etc.
O controle de estoques era um caso à parte, pois tinha de trabalhar com memória compartilhada (isso somente é possível em Assembly ou LM).
Era mais ou menos assim: Um produto ocupava a metade direita da memória, e outro produto a metade esquerda.
Então tinha-se de "enganar" aqueles registradores que ficam no final de cada byte.
Ainda bem que esse "pulo do gato" foi ensinado pelo próprio pessoal de suporte do fabricante.
Tinha um analista de suporte em especial que era "feríssimo" e extremamente modesto.
O cara sabia de tudo e mais alguma coisa...
E a insTruTora de Assembly era Também um fenômeno de simpatia e de conhecimento de causa.
Nem precisava ser Tão bonita e charmosa, eTc.
