Compreendendo os níveis de computação

Desculpe, pela minha pergunta confusa. Estou procurando algumas dicas.

Até agora, tenho trabalhado principalmente com Java e Python na camada de aplicativos e tenho apenas uma vaga compreensão de sistemas operacionais e hardware. Eu quero entender muito mais sobre os níveis mais baixos da computação, mas fica realmente impressionante de alguma forma. Na universidade, participei de uma aula sobre microprogramação, ou seja, como os processadores se conectam para implementar os códigos ASM. Até agora, eu sempre pensei que não faria mais se aprendesse mais sobre o "nível baixo".

Uma pergunta que tenho é: como é possível que o hardware oculte quase completamente do desenvolvedor? É preciso dizer que o sistema operacional é uma camada de software para o hardware? Um pequeno exemplo: na programação, nunca me deparei com a necessidade de entender o que é o cache L2 ou L3. Para o ambiente típico de aplicativos de negócios, quase nunca é preciso entender o montador e os níveis mais baixos da computação, porque hoje em dia existe uma pilha de tecnologias para quase tudo. Eu acho que o objetivo desses níveis mais baixos é fornecer uma interface para níveis mais altos. Por outro lado, me pergunto quanta influência os níveis mais baixos podem ter, por exemplo, toda essa coisa de computação gráfica.

Por outro lado, existe esse ramo teórico da ciência da computação, que trabalha em modelos abstratos de computação. No entanto, também raramente encontrei situações em que achei útil pensar nas categorias de modelos de complexidade, verificação de provas etc. Eu meio que sei que existe uma classe de complexidade chamada NP e que é meio impossível de resolver. um grande número de N. O que estou perdendo é uma referência para uma estrutura para pensar sobre essas coisas. Parece-me que existem todos os tipos de campos diferentes, que raramente interagem.

Nas últimas semanas, tenho lido sobre problemas de segurança. Aqui, de alguma forma, muitas das diferentes camadas se juntam. Ataques e explorações quase sempre ocorrem no nível inferior; portanto, neste caso, é necessário aprender sobre os detalhes das camadas OSI, o funcionamento interno de um sistema operacional, etc.

A palavra-chave para pensar sobre essas coisas é abstração .

Abstração significa apenas ignorar deliberadamente os detalhes de um sistema para que você possa pensar nele como um componente único e indivisível ao montar um sistema maior a partir de muitos subsistemas. É inimaginavelmente poderosa - escrevendo um programa de aplicação moderna ao mesmo tempo considerando os detalhes de alocação de memória e registrar derramar e tempos de execução transistor seria possível, de alguma forma idealizada, mas incomparavelmente mais fácil é nãopensar sobre eles e usar apenas operações de alto nível. O paradigma da computação moderna depende crucialmente de vários níveis de abstração: eletrônica de estado sólido, microprogramação, instruções de máquina, linguagens de programação de alto nível, APIs de programação de SO e Web, estruturas e aplicativos programáveis ​​pelo usuário. Virtualmente, ninguém poderia compreender todo o sistema hoje em dia, e nem existe um caminho concebível pelo qual possamos voltar a esse estado de coisas.

O outro lado da abstração é a perda de poder. Ao deixar as decisões sobre os detalhes em níveis mais baixos, geralmente aceitamos que elas sejam tomadas com eficiência abaixo do ideal, uma vez que os níveis mais baixos não têm o 'Big Picture' e podem otimizar seu funcionamento apenas pelo conhecimento local e não são (potencialmente) inteligente como ser humano. (Geralmente. Por exemplo, hoje em dia, compilar HLL em código de máquina costuma ser melhor feito por máquinas do que pelo ser humano mais experiente, já que a arquitetura do processador se tornou muito complicada.)

A questão da segurança é interessante, porque falhas e 'vazamentos' na abstração geralmente podem ser exploradas para violar a integridade de um sistema. Quando uma API postula que você pode chamar os métodos A, B e C, mas apenas se a condição X for mantida, é fácil esquecer a condição e não estar preparado para a precipitação que ocorre quando a condição é violada. Por exemplo, o estouro clássico de buffer explora o fato de que gravar nas células da memória gera um comportamento indefinido, a menos que você tenha alocado esse bloco específico de memória. A API garante apenas que algocomo resultado, mas, na prática, o resultado é definido pelos detalhes do sistema no próximo nível inferior - do qual esquecemos deliberadamente! Desde que cumpramos a condição, isso não tem importância, mas, se não, um invasor que entenda os dois níveis intimamente pode normalmente direcionar o comportamento de todo o sistema conforme desejado e fazer com que coisas ruins aconteçam.

O caso dos erros de alocação de memória é particularmente ruim, porque acabou sendo muito, muito difícil gerenciar a memória manualmente sem um único erro em um sistema grande. Isso pode ser visto como um caso de abstração com falha: embora seja possível fazer tudo o que você precisa com o CmallocAPI, é simplesmente fácil de abusar. Agora, partes da comunidade de programação pensam que este era o lugar errado para introduzir um limite de nível no sistema e, ao invés disso, promover linguagens com gerenciamento automático de memória e coleta de lixo, que perde um pouco de energia, mas fornece proteção contra corrupção de memória e comportamento indefinido . De fato, uma das principais razões para o uso do C ++ atualmente é justamente o fato de permitir controlar exatamente quais recursos são adquiridos e liberados quando. Dessa maneira, o grande cisma entre as línguas gerenciadas e as não gerenciadas atualmente pode ser visto como um desacordo sobre onde definir com precisão uma camada de abstração.

O mesmo pode ser dito de muitos outros paradigmas alternativos importantes na computação - a questão realmente surge o tempo todo em que grandes sistemas precisam ser construídos, porque somos simplesmente incapazes de projetar soluções do zero para os requisitos complexos comuns hoje em dia. (Um ponto de vista comum no AI nos dias de hoje é que o cérebro humano realmente faz o trabalho assim - comportamento decorrente através de loops de feedback, redes maciçamente interligados etc., em vez de módulos separados e camadas com simples, interfaces abstratas entre eles, e que é por isso que tiveram tão pouco sucesso em simular nossa própria inteligência.)