Montar um PC: quais são os passos a tomar ...

isac__sycard · 15 de agosto de 2015

Bom dia, boa noite a quem ler e pensar neste post

tenho um sonho

- Quero montar um pc,mas de forma mais acentuada, destes dos efeitos da CPU,tenho um amigo que dize que quer juntar se a esse projeto,claro que tenho que estudar muito, por muitas noites,pra melhorar cada vez mais, e queria ver pequenas ajudas para melhor encaminhamento deste sonho, mas o hardware, vai se comprado, normalmente devo instalar o SO linux,pra começar, mas só pra começar a desenvolver, mas o karnel queria começar a controlar, pois o meu amigo quer começar a criar um simples sistema operativo, sei que devemos saber de começo saber assembly pra controle da CPU,cooler assim como a sua derivada de velocidade,overclock processador,RAM,placa de video,queria pedir exemplos,riscos,e limites de overclock de processador,e como modificar isso por assembly,exemplo mudar overclock processador por assembly por CPU Vcore: tensão da CPU (volts) CPU External Frequency ,CPU Multipler, CPU Frequency Multipler,por ai fora eu preciso tambem de saber aumentar a velocidade do cooler em 20% até 40%,calculando em relação a CPU pela temperatura, queria saber como diminuir também velocidades,volts em assembly .... não me importo de ficar noites sem dormir,agradeço respostas e tambem conselhos detelhados

como poderie fazer a CPU ter velocidades constantes por assembly

Google Do Bing · 15 de agosto de 2015

pra você fazer um sistema operacional você tem que entender C# e C++,os coolers da CPU não são controlados pela placa mãe ? a unica coisa que você vai ter que fazer e reconhecer memoria ram hd placa de vídeo tipo do processador tudo isso

aphawk · 15 de agosto de 2015

@isac__sycard,

Nossa, isso que é sonho !!!!!

Bom, eu vou te passar algumas dicas da minha época..... mas devem ser válidas ainda.

Primeiro, o que voce tem de saber mesmo não é o Assembly, e sim o C. Como eu não entendo patavina de C, nem sei te dizer se é C, C++, C ANSI ou sei lá o que C..... mas é simplesmente quase impossível fazer isso em Assembly. Até o MSDOS já tinha muita parte dele em C, e isso em 1984 ....

Quanto ao gerenciamento da CPU, existem API's dos próprios fabricantes para fazer isso. Elas permitem modificar o funcionamento em tempo real, mas confesso que nunca tive a curiosidade de ver isso.

Para fazer o Overclock, não depende só do software. Existem condições espeçificas de hardware para fazer um bom overclock, como memórias que possas acompanhar todos os timing envolvidos, e principalmente conheçer MUITO sobre o chipset que será utilizado.

Aliás, o chipset é muito mais importante de se conheçer do que a CPU..... ele faz tudo, controla tudo, sabe de tudo. A CPU vira um mero escravo disso tudo.

Agora, após te falar isso acima, vou ser bem mais objetivo : Da maneira que voce escreveu, esse sonho precisaria de muita gente envolvida, e cada uma responsável por uma pequena parte desse todo. Em duas pessoas, é totalmente impossível.

Boa sorte !

Paulo

victhor393 · 15 de agosto de 2015

Parâmetros controlados pela placa-mãe só podem ser acessados por chamadas ACPI, que normalmente não são documentadas. Ou seja, esqueça ajuste de Vcore. Cooler é até mais fácil, dá para acessar o Super-IO bem fácil (relativamente) usando portas de I/O ISA, desde que tenha o datasheet do mesmo, isso não será um problema. Os parâmetros do processador, como multiplicador, podem ser ajustados pelos MSRs do processador se disponíveis. Mas vou ser sincero, isso é o que eu acho que você quer fazer... porque seu texto está absolutamente horrível. Formule um texto melhor, talvez consiga ajuda se outros entenderem o que você quer fazer.

isac__sycard · 16 de agosto de 2015

Obrigado pelos comentarios

Dizeram me que com assembly se podia controlar ate os cooler,mas dá pra aumentar volts e frequencias de um processador,mas cooler acreditava por saber que assembly recorre ao baixo nivel

victhor393 · 16 de agosto de 2015

Não precisa de asm (assembly), não precisa rodar exclusivamente, essas coisas dá pra fazer até num SO, com linguagem de alto nível mesmo. Só que tem que usar um driver, não dá para fazer em espaço de usuário como na época do DOS. Afinal de contas, o SO precisa de acesso ao hardware para mostrar coisas na tela, ler o teclado, mouse, dispositivos USB, então, obviamente, deve ser possível.

AMD Overdrive permite ajustar multiplicador, FSB pelo SO. SetFSB fazia a mesma coisa nos Core 2. SpeedFan controla velocidade do cooler, se suportado, do SO. Utilitários proprietários de muitas placas-mãe permitem ajuste de Vcore, velocidade de coolers, configuração de curvas do controle automático de cooler da placa, etc. Nenhum desses precisa rodar de forma independente do SO...

Qualquer linguagem compilada produz um binário que pode realizar funções idênticas a de um binário gerado por um assembler, alguns compiladores até produzem asm a partir da linguagem de alto nível como um passo intermediário antes de usar o assembler para gerar o binário, acho que o GCC faz isso. Asm não é mágica, diferente do que muita gente pensa, praticamente tudo que pode ser feito em asm, pode ser feito em uma linguagem de alto nível compilada e vice-versa. A exceção é acesso direto aos registradores do CPU, como os MSRs em processadores x86, nesse caso é necessário o uso de asm.

aphawk · 16 de agosto de 2015

@victhor393,

O Asm "faz mágica" sim !

Mágica de ter o controle total da CPU, usar eficientemente os recursos dela, e principalmente permitir ao programador usar o algoritmo que lehe dá a maior performance usando as instruções certas para esse processador. Mas o problema é o tempo desperdiçado para atingir esse resultado.

Infelizmente, hoje em dia até um SO está sendo feito em linguagem de alto nível.

Me dá muita saudade da época onde o Kernel era inteirinho em Assembly, como no Windows até o 3.1 . Tudo era muito rápido e o tamanho muito pequeno.

Para instalar um Msdos e um Windows 3.1, eram necessários 14 disquetes de 1.44 Mb !!!! E quando instalados, ocupava menos de 10Mb tudo, o que fazia com que meu HD NEC de 65Mb ficasse imenso em capacidade !

Fora que entre dar o Beep de quando ligava o computador, e aparecer o prompt do MSDOS, demorava menos de 3 segundos. Após digitar WIN e teclar ENTER, mais 2 segundos e pronto, aparecia o Windows 3.1 . Ao clicar com o Mouse no Icone do Excel, mais 1 segundo e pronto, já podia usar ! E isso com um 486 rodando a 120 Mhz, e 16 Mb de Ram, onde a memória rodava a 66 Mhz de clock, e não existiam os caches de hoje em dia !!!!

Hoje, olhando meu computador, um Core i3 ( três núcleos !!!!) rodando a 2.5 Ghz , com 16 Gb de RAM com velocidade de 1.66 Ghz e bem mais memória cache interna do que a existente em meu antigo 486 e em vários pipelines..., 3 HDs em Raid0 com 2 Tb cada um cuja velocidade ultrapassa em mais de 30 vezes meu antigo Nec de 65 Mb.... e mesmo assim parece que tenho uma carroça que demora um tempão prá carregar, prá abrir outros programas, e ocupa duas dezenas de Gigabytes de espaço apenas para uma instalação básica com Office !!!

É mais bonito ? É .

Dá para fazer muito mais coisas ? Sim.

Mas esse tamanho absurdo, esse uso absurdo de memória, e mesmo com um processador que deve passar de 50 vezes a velocidade que tinha o meu 486, resulta em algo duro de engolir : LENTIDÃO .

Isso é o preço que pagamos por escreverem tudo em linguagem de alto nível, e a centenas de mãos !

Já imaginaram se o pessoal do Linux tivesse começado naquele tempo do Windows 3.1 e continuassem fazendo o Kernel totalmente em Assembly, aonde estaríamos hoje em dia ?

@isac__sycard,

voce pode fazer sim tudo em Assembly, mas vai demorar dezenas de vezes mais tempo do que usar uma linguagem de alto nível e milhares de bibliotecas prontas que existem na Internet. Que aliás é o que todos fazem, e porisso fica tudo uma lentidão absurda..... Mas reinventar a roda custa muito tempo e dinheiro, e isso justifica tudo.

Quanto as API's, realmente é o que o Victor falou acima. Quase nenhuma documentação vaza para nós, simples consumidores...

Paulo

victhor393 · 17 de agosto de 2015

Discordo. Compiladores modernos são bastante poderosos e capazes de produzir binários bastante eficientes se suas otimizações forem usadas. Seria necessário um nível de conhecimento muito elevado sobre a arquitetura para conseguir competir com um compilador C moderno. Programas de alto nível de complexidade seriam praticamente impossíveis de fazer funcionar devido à dificuldade de debugar asm.

O que você está observando é simplesmente o fato desses programas terem se tornado bastante pesados em questão de funcionalidades conforme o hardware vai se tornando mais capaz. Ícones e imagens em geral de alta resolução, em formatos comprimidos, em grande número, resultam em tempos de carregamento muito grande e muito uso de memória, já que tudo isso tem que ir para a memória. E isso é uma coisa muito comum hoje, já que monitores possuem resoluções consideravelmente maiores que antes. Por isso que tem gente que bota SSD no PC e se surpreende com o resultado... os programas têm que carregar tanta coisa, mas tanta coisa, que o fator limitante passa a ser o número de operações de I/O que o disco é capaz de realizar! Como um SSD é muito melhor nesse quesito que um HD mecânico, ele deixa de ser o fator limitante e isso deixa de ser um problema.

Inclusive, estive usando Linux 3.19, logo, uma versão recente, em um sistema MIPS com apenas 32 MB de RAM e processador de 300 MHz. Também já fiz o mesmo em um dispositivo com uma tela 320x240 e processador ARM de 312 MHz, também com 32 MB de RAM, era uma versão um pouco mais antiga que essa, mas da mesma série. Não notei problemas de performance na interface gráfica, mas não é de se surpreender... os programas em ambos os casos eram, relativamente falando, mais simples que seus equivalentes em sistemas "maiores", portanto funcionavam de forma adequada (um pequeno detalhe, um possuía uma memória flash de 4 MB para armazenar o SO e seus utilitários, e o outro 8 MB). Acredito que na época do 2.4.x era possível rodar em 16 MB de RAM, hoje isso não é mais possível, devido à quantidade de funcionalidades que foram integradas ao kernel. Esta é a desvantagem de um kernel monolítico como o Linux, não é um problema "C vs asm". Talvez até o Windows se dê bem aqui, já que ele usa um microkernel, mas seria necessário muito trabalho para tirar tudo o que não é absolutamente necessário para o SO funcionar - como no Linux.

Tanto a versão MIPS quanto ARM possuem pouquíssimo, ou talvez nenhum, asm em seu código. Os desenvolvedores estão cuidando de tirar o que resta de asm da versão x86, porque está se tornando difícil de manter com as mudanças realizadas durante o tempo.

felipe236 · 17 de agosto de 2015

Da para controlar um cooler usando até um Arduíno mais simples que existe hehehe.(aqueles de 4 fios é mais fácil ainda.)

lembrando que a maioria das placa mãe não controla os cooler (a placa mãe tem um circuito de alimentação acoplado a placa e apenas recebe o sinal rpm que vem de um circuito interno que existe no cooler( aquele fio amarelo e ao abrir um cooler vai ver um C.I que aciona e monitora, detecta a posição(sensor Hall) e as rotações e envia a informação em rpm para placa.)

Se você prender um cooler vai ver que ele não alimenta de forma continua e não oferece muita resistência a obstrução., (fica parado e em instantes começa rodar de novo o C.I reinicia e tenta rodar a fan mais umas vez.

Já as mais atuais e um pouco mais caras tem um 4 terminal que manda para para circuito pwm interno do cooler para controlar a velocidade.( funciona se cooler for daquele de 4 fios.) se o cooler for 3 fios não tem como controlar amenos que tenha um circuito pwm externo.

Fazer um S.O e muito ***** nem eu penso nisso simplesmente usaria um PIC ou Arduíno. usar a linguagens conhecida

para controlar não precisa ser muito potente. o computador dos ônibus espaciais só tinha um míseros 416kb de ram com processador de 1,4 mhz.(1,4 milhões de instruções por segundo). controlava tudo mesmo, toda parte eletrônica/mecânica/elétrica e até na hora de pousar.

Aqui explica como criar sua linguagem de programação e seu compilador único pessoal.

https://sites.google.com/site/tecguia/home/crie-sua-propria-linguagem-seu-proprio-compilador

aphawk · 17 de agosto de 2015

@victhor393,

Eu tenho um SSD no Boot, um Corsair SATA6 de 120 Gb. Quando instalei o Windows 7, sem mais nada, ficou bem mais rápido. Mas foi só encher o Windows de programas e pronto, nem percebo mais que é um SSD. E hoje, quase um ano depois, é um fator limitante. E ainda não entendo como com 16Gb de RAM, e SO de 64 bits, toda hora tem de fazer temporário no HD ......

Isso de discutir C x Asm existe desde os meus tempos de programador.....

Se voce vai fazer um programa simples, onde não precisa de desempenho, eu nem vou discutir, pois o tempo necessário a terminar o código em Asm simplesmente seria muito maior, e nem existe a necessidade.

Agora, imagine uma coisa : eu estou fazendo um analizador lógico, e mesmo se fosse feito inteiramente em C, seria bem mais lento do que o código em Asm. O que é bem mais lento neste caso ? Pelo menos duas a três vezes mais lento. E o tamanho seria mais do que o dobro do código em Asm.

Aqui é que entra o conhecimento de hardware : nenhum compilador sabe tudo sobre o sistema onde está rodando, nem sobre o hardware usado. Já um bom programador ASM é OBRIGADO a conheçer bem a fundo o sistema, e isso dá muitas vantagens.

Concordo que hoje em dia conheçer profundamente um computador em termos de hardware é muito difícil, ainda mais aqui no Brasil..., e mesmo conheçer exaustivamente a arquitetura de um moderno Core I7 , com todos os seus núcleos e diversos pipelines separados e ainda os caches primários e secundários não é para qualquer um. Mas quem conhece pode tirar muito mais resultados disto do que um simples compilador poderia, aproveitando os núcleos, os processos, e redesenhando o fluxo de programa , inclusive observando como fazer um algoritmo melhor para aproveitar todo o recurso de hardware existente.

Mas fazer um SO inteiramente em ASM, isso sim é um sonho hoje em dia, pois apenas escrever os drivers para todos os hardwares possíveis levaria centenas de programadores à loucura completa !

E cada vez mais os desenvolvedores estão abandonandoo Asm pelo seu alto custo de desenvolvimento e dificílima integração de trabalho entre vários programadores.

É o custo do progresso.... temos de ficar trocando os hardwares de tempos em tempos pois os programas ficam cada vez mais lentos....

Paulo