"Leonardo T. de Carvalho" wrote:

>     Pois �, quem aprendeu a fazer um compilador na faculdade ( FALA�
> PATOLA! =O) sabe o tanto

Ulha! Temos um guru na lista!! Ei Patola, o seu compilador gerou c�digo?
O meu s� gerou dor de cabe�a... 8-D 8-D 8-D 8-D 8-D 


> que � dif�cil, mas qdo se tem uma empresa com nego que tem de
> experi�ncia nisso o que eu tenho
> de negativo na conta do banco (=o) o m�nimo que eles podiam fazer  usar
> essas instru��es SEMPRE
> que poss�vel,

A� � que t�. Ser� que existem tantos gurus de compiladores assim
dispon�veis?

Desde os tempos da Jensen & Partners (brinquei muito com os compiladores
da JPI) que os "grandes" nomes dos compiladores s�o os mesmos...

A JPI foi formada com programadores da Borland, que n�o gostaram do
tratamento que ela estava dando ao compilador que eles ajudaram a
escrever. Da �ltima vez que soube deles, eles trocaram o nome da firma e
estavam vendendo uma solu��o visual de banco de dados (esqueci os
detalhes, se algu�m se interessar, corro atr�s de novo).

S� um detalhe : os compiladores da JPI geravam um c�digo que deixavam o
do BP parecendo coisa de amador.

Do pessoal da Borland que sobrou na �poca (e que foram respons�veis
pelos compiladores da Borland depois do "racha"), boa parte foi
contratada pela Microsoft.


>  afinal elas s�o somente um jeito de atochar a maior
> quantidade poss�vel de dados
> nos pipelines/barramento usando o menor n�mero poss�vel de ciclos...

� mais ou menos isso mesmo.

Como os x86 s�o tudo CISC, fica complicado usar pipelines de forma
decente, j� que os bytecodes na verdade s�o convertidos numa s�rie de
micro-instru��es, estas sim executadas efetivamente pela m�quina (bem
estilo interpretador BASIC dos anos 80).

Como a convers�o � feita "on-the-fly", fica muito caro escrever um
reescalonador de "micro-intru��es" em hardware dentro do chip para fazer
o que os compiladores RISC fazem com as instru��es RISC :
reescalonamento de c�digo para otimizar o uso do processador.

(nota : o Itanium tem exatamente isto : um "compilador" de x86, com
otimiza��o, implementada em hardware dentro do chip - coisa de louco)

Falando nisso, sabe como foi implementado pipeline nos x86, � partir do
486? Duplica��o de componentes... O 486 tem o equivalente � dois 386 em
paralelo, embora n�o independentes. � por isto que o 486 � t�o mais
r�pido que os 386, ele pode executar duas intru��es quase
simult�neamente (na verdade, o que � executado simult�nemante � o
micro-c�digo).

Os Pentium da Intel possuem 4 "386"s, e os AMD-K6 possuem 6.

� por isto que o aumento de performance n�o � escalar, n�o se aumenta
apenas o clock, mas sim a estrutura interna dos processadores.

ps: dei uma simplificada braba neste papo de "386"s embutido, n�o levem
exatamente ao p� da letra...

-- 
[]s,
([EMAIL PROTECTED])

Liberdade n�o � um esfor�o individual.
A sua s� existe se vc garantir a dos outros!

Vapour : The Software's natural state.

Assinantes em 27/06/2002: 2218
Mensagens recebidas desde 07/01/1999: 172988
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
            mailto:[EMAIL PROTECTED]

Responder a