| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Indica e que /caso/ o itanio seja um flop, a intel nao quer ficar em posicao de dar o mercado a AMD.
Seja como for, acho provavel que o itanio tenha o mesmo destino que o pentio pro.
--- |
| | | | | | Não tem nada a ver o pentium pro era basiado em X86 e 100% compativel com aplicações anteriores. Estamos a falar de outra arquitectura que não tem nada a ver com a x86.
|
| | | | Existem, pelo menos superficialmente, semelhancas:
1. Os 2 processadores foram apresentados a partida como solucoes proficionais para servidores
2. Ambos os processadores sao *revolucionarios* a sua maneira, correndo software antigo menos eficientemente que os processadores actuais. Na altura acho que se dizia que corria x86 de 16bits em modo de emulacao.
3. E substancialmente mais caro que tudo o resto.
Existe a possibilidade que o novo processador 64/32 da intel va desemprenhar um papel semelhante ao do pentium 2: um compromisso de design/performance que acaba por cortar por baixo o processador topo de gama.
--- |
| | | | E deves tar a pensar que o core dos CPU's de hoje não é RISC ?
Uma coisa não tem nada a ver com a outra.
|
| | | | O Pentim Pro foi o primeiro processador da muito bem sucedida aquitectura P6, a mesma dos Pentium II e III.
Mas no PentiumPro, os designers investiram pouco na execução de código de 16 bits e vinha equipado com 512 kB ou 1 MB de cache L2. Ou seja, um processador caro que não executava eficientemente a maioria do código existente na altura. Isso foi corrigido no Pentium II. Contudo, a linha de processadores orientados para um uso mais "profissional" continuou com os Pentium II Xeon, Pentium II equipados com maiores caches L2.
O núcleo da arquitectura P6, assim como as que lhe sucederam (incluindo as da AMD), baseia-se na conversão de intruções x86 em µOPs RISC-like.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | | ...tecnologia RISC... RISC é um conceito, e muito simples: ISAs mais simples permitem conceber chips que executem uma tarefa mais rapidamente que um chip baseado numa ISA CISC.
Não me lembro da Intel ter alguma coisa a ver com a Digital na altura. A Digital estava demasiado ocupada a afundar-se financeiramente e a ser comprada pela Compaq.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | Naquela altura o alpha da Digital ainda era o melhor, a história da compra da compaq foi depois.
Os melhores pentium eram 150-166 MHZ (foi nessa altura que apareceu o pentium pro) e os Alpha já antigiam 233-266 e eram 64bits-risc, corriam cerca de 3 vezes mais depressa que os intel.
Hoje é o contrario os Alpha com 1000 mhz e os pentium com 2.2 Ghz ,a velocidade real embora seja parecida os pIV já levam vantagem.
Daqui a mais 5 anos os Alpha já não se fabricam
e os Intel 32 Bits devem passar a barreira dos 10 Ghz.
|
| | | | Sim, mas o facto de o Alpha ser uma execelente tecnologia não impediu o fracasso comercial. Já nessa altura a Digital se estava a afundar. E nem a Compaq conseguiu rentabilizar o Alpha...
Momento de nostalgia...
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | > O PIV e o unico core realmente novo que a intel fabrica desde o Pentium Pro (pelo menos nos x86).
Hummmm, não. O pIV é exactamente o mesmo core com um pipeline mais comprido. Por isso é que é a boxta que se vê.
|
| | | | Nada a ver... Pipe line mais logo, um decoder unificado, µOPs mais pequenas, Trace Back Cache em vez de Cache L1 para código, ALUs capazes de fazer uma soma em meio ciclo, etc, etc...
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | Hmm (Pontos:3, Interessante) |
| | A intel deu vários tiros no pé com o adiamento indefinido do Itanium o que deu à concorrência tempo para desenvolver produtos concorrentes. Quiseram gerar falatório anunciando datas de lançamento antes do Itanium estar sequer pronto para testes agora correm atrás da AMD.
E na minha opinião a arquitectura do Hammer da AMD não é nada má ideia até porque acaba por ser dois procesadores em um e faz aquilo que já devia ter sido feito ao x86 à bastante tempo, adição de novos GPRs (General Purpose Registers) em vez da simples extensão destes para 64bits.
Sendo o Hammer a aparecer primeiro no mercado e se este conseguir alguma popularidade mesmo que o modo de 64 bits puro seja apenas usado em servidores com Linux ou assim a Intel será obrigada a segui-los e talvez, se tudo correr bem o modo de compatibilidade de 32bits seja atirado às urtigas e, tenhamos então algo que já não é bem x86 mas também não deixa de ser.
-- Carlos Rodrigues
|
| | | | | | | Se bem que a Intel e a HP tenham dado vários tiros no pé com os adiamentos, a verdade é que ainda não andam por ai chips a dizer "AMD Hammer". E não devemos ver antes do primeiro trimeste de 2003 (a não ser que também o Hammer sofra mais adiamentos). Mas IA-64 tem muito mais apoio.
Fala-se muito na falta de software para IA-64 mas parece muito melhor que x86-64.
Linux, HP-UX, AIX, IRIX e Windows a correr lá. Solaris e FreeBSD a caminho.
x86-64 tem Linux e NetBSD a caminho mas não se vê mais nada no horizonte. Em particular, não se vê Windows, o que é crucial para a AMD enquanto não houver um penguim a dominar o mundo. E sabendo como a M$ é aversa a fazer ports do Windows a coisa não parece boa.
Havendo compiladores e sistemas operativos, o resto do software é um problema menor. O software para Windows é o mais complicado. Acredito que haja por ai muitas linhas de C/C++ para Windows que assumem tamanhos dos tipos e que coloquem problemas em ser portado para 64 bits. Mas isso aplica-se tanto a IA-64 como x86-64. O software para *nix deve ter menos problemas com isso e os programadores estão mais habituados a lidar com uma variedade de arquiteturas, sistemas operativos e compiladores. No mercado high-end a questão parece clara: IA-64 or bust. Ou seja, IA-64 ou ficam como estão. Os fabricantes não irão trocar os processadores RISC que usam por x86-64 nem x86-64 tira partido da compatibilidade com x86. Algumas (IBM, por exemplo) nem pretendem abandorar completamente as suas arquitecturas RISC actuais em favor de IA-64. No resto a coisa é um pouco mais complicada e depende seriamente de haver ou não suporte para Windows. Ou será que a AMD se safa só com o pessoal que corre principalmente Linux e NetBSD?
Mesmo que a M$ faça um port do Windows, que suporte vai haver para uma ISA que a Intel não suporta? Não estamos a falar de meia dúzia de instruções como MMX, SSE ou 3dNow!. Diga-se o que se disser, as coisas parecem-me ir mais ou menos pelo caminho da Intel: IA-64 no mercado high-end, com tendência a expandir-se para baixo e x86 a continuar a dominar o low-end. Uma nota: a questão não é 32 bits vs 64 bits. Estamos a falar de duas ISAs totalmente diferentes, baseadas em conceitos dispares.
Mesmo que x86-64 se popularize, a AMD não vai atirar a compatibilidade com 32 bits pela janela, tal como a Intel nunca fez o mesmo com o suporte para 16 bits. Primeiro, os processadores x86-64 vão continuar a arrancar em modo real, como se faz desde os 8086 para garantir 100% de compatibilidade com x86. Logo, um OS para x86-64 vai continuar a precisar d o modo real para arrancar, tal como os OS para x86 que correm em modo protegido actualmente precisam.
Além do mais, mesmo em código gerado para x86-64 vai haver a necessidade de manipular blocos de dados com menos de 64 bits. E tal como se fez em x86, isto é feito usando registos parciais. Logo, não há razões para remover suporte a 32 bits.
Logo, remover suporte para x86 não é uma opção. De qualquer maneira, também não representa um problema, uma vez que a estrutura das instruções é semelhante.
Já em IA-64, o suporte para x86 é algo que apareceu ali de pára-quedas e é natural que surjam chips em que ele não exista. De qualquer maneira, no estado actual, o suporte para x86 em IA-64 parece uma piada de mau gosto. Pessoalmente, torço pela Intel. x86 é tão velha como eu, estou farto dela!
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | Mas não se pode esquecer um pormenor... a intenção da AMD não é posicionar o Hammer como 64bits only, a intenção deles é saltar do Athlon para o Hammer como processador de 32bits, não fazendo do modo de 32bits um simples modo de compatibilidade. Penso que a ideia é cobrir a rectaguarda, ir metendo o Hammer como processador para servidores no modo de 64bits e a pouco e pouco fazer isto também no desktop. Também acho que é extremamente difícil tirar o mercado desktop ao x86 mas fazendo um processador 2 em 1 em massa reduz os custos e faz com que as empresas o encarem como encaram o x86, reduzir os custos. Por um lado combate o Itanium facilitando o port de aplicações e possívelmente mesmo em desempenho. Por outro lado poe um processador de 64bit escondido nos PCs do pessoal, à espera dos curiosos dos free *nixes para o usar e que a Microsoft acorde para ele.
-- Carlos Rodrigues
|
| | | | Absolutamente correcto.
Mas enquanto a M$ e os outros fabricantes de software não acordarem, x86 vai ser dominar e x86-64 vai ser apenas uma curiosidade. Se a Intel fizer um esforço para impor IA-64 nos desktops antes de x86-64 ter uma posição forte, a AMD está tramada. Para piorar, as únicas vantegens que x86-64 tem sobre x86 são endereçamento a 64 bits (que precisa de sistemas operativos desenhados para tirar partido disso) e (mais alguns) registos de uso geral de 64 bits.
A FPU não vai ser expandida, porque as actuais FPUs (que também dão suporte às intruções SIMD: MMX, SSE, 3dNow!, etc)de x86 já suportam 64 bits. Dai x86-64 não leva vantagem sobre x86...
A quantidade de software que vai tirar partido dos registos de uso geral de 64 bits parece-me algo limitada. É que, ao contrário das arquitecturas modernas, x86 e x86-64 desperdiçam bastante a capacidade dos seus registos quando é necessário lidar com dados menores que word (tamanho dos registos).
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | Não sei porquê mas parece-me que nem que os porcos voassem a intel conseguiria impor o IA-64 no desktop a curto ou médio prazo. Até porque, como já disseste, o suporte de 32bit do Itanium é uma anedota (lento).
Quanto aos novos GPRs eu penso que são um valor acrescentado porque o compilador tem mais espaço com que brincar, mas o facto de não poderem ser usados como 32bit (tal como os primeiros 8) lhes tira alguma da utilidade (porque penso que o tipo "int" continuará a ser 32bit com o "long" de 64 para não haver explosão das necessidades de memória).
-- Carlos Rodrigues
|
| | | | | Isso é uma grande verdade. Pelo menos com o suporte para IA-32 no estado actual. Mas nunca se sabe que trunfos a Intel tem na manga. Empresas destas não dão ponto sem nó. Os novos GPRs de x86-64 podem ser usados em 32, 16 e 8, de uma maneira semelhante (mas não totalmente igual) ao que se faz com os actuais GPRs.
Ler mais... E 8 registos sempre são 8 registos, numa arquitecura que só tinha 4 de uso geral e 2 outros assim assim. Isto é bom, não só para manter mais dados em registos como pelo espaço que dá para gerar código que possa ser executado em paralelo.
Mas a expansão a 64 bits em si é limitada. O único benificio é podermos fazer operações com inteiros de 64 bits numa única instrução usando registos de uso geral (e a questão do endereçamento de memória a 64 bits).
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | > Não sei porquê mas parece-me que nem que os porcos voassem a intel conseguiria impor o IA-64 no desktop a curto ou médio prazo.
Especialmente considerando que um Itanium custa mais que um PeCe :)
> Até porque, como já disseste, o suporte de 32bit do Itanium é uma anedota (lento).
É um 486. Não é a mesma velocidade que um 486, é mesmo um core 486 metido a martelo depois de descobrirem que era mais mais fácil que fazer um tradutor ia64 -> x86
> Quanto aos novos GPRs eu penso que são um valor acrescentado porque o compilador tem mais espaço com que brincar, mas o facto de não poderem ser usados como 32bit (tal como os primeiros 8) lhes tira alguma da utilidade
Pôr os registos novos acessiveis de 32 bits não vale o esforço. As aplicações teem que ser recompiladas para os usar e nesse caso mais vale recompilar directamente para Long Mode (nota que de qq modo não corriam noutros x86)
|
| | | | Pôr os registos novos acessiveis de 32 bits não vale o esforço.
Eu falava de poder usar os novos registos para conter valores de 32bits não de serem acedidos a partir do modo de 32bits. Mas seguindo o link do post acima pode ver-se que os novos GPRs também podem ser subdivididos tal como os GPRs que já existem, assim sim, mais 8 registos fazem uma grande diferença em termos de performance (muito menos acessos à memória).
-- Carlos Rodrigues
|
| | | | Expões os novos registos a código x86-32. Agora precisas de um compilador que saiba que eles estão lá. Simples, basta mudar uma definição no gcc. Agora precisas de ajustar o alocador de registos para os usar *bem* em vez de estar sempre na miséria dos registos actuais. Depois de o escreveres precisas de recompilar as tuas aplicações com o compilador novo. Os binários só correm no Hammer, e provavelmente dão resultados imprevisiveis em todos os outros.
O que é que ganhaste em relação a saltar directamente para x86-64 ? :)
O processador pode é usar os registos extras como scratch quando está a fazer execução expeculativa como o athlon faz até certo ponto, mas nunca vi nada escrito a dizer que sim ou não. De qualquer modo isto é transparente para o código.
|
| | | | | Primeiro: Não expões. Os novos registos só estão disponiveis em 64 bit mode. Uma má estratégia da AMD. Assim, só vai surgir código especifico de x86-64 para SOs que suportem o 64 bit mode. Se os registos extra fossem acessiveis a partir de Legacy Mode, podias escrever programas que correm em Win32 por exemplo mas que tirassem partido de x86-64. Claro que não iam correr noutro chip mas nem todos os processadores x86 suportam MMX ou SSE. (ok, n é exactamente a mesma coisa, mas...).
Sempre ias contruindo uma base de software que necessite que tira vantagem de x86-64 sem necessidade de um OS que suporte 64 bit mode.
Assim, sem um OS, comprar um chip que suporte ou não x86-64 vai dar ao mesmo. Segundo, o CrLf estava a referir-se à possibilidade de usar os 8 novos GPRs para manipular dados de 8, 16 ou 32 bits, nada relacionado com o modo do processador. Scratch? Execução especulativa? Isso não tem nada a ver. Internamente os processadores têm os registos que forem precisos. Seja num Pentium ou num Athlon, os registos visiveis são mapeados em registos internos como o processador achar mais conveniente.
Estamos a falar de registos que sejam visiveis para o código.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | Mas Long Mode requer um OS que suporte x86-64...
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | "Pessoalmente, torço pela Intel. x86 é tão velha como eu, estou farto dela"
Exactamente, Ainda vai continuar durante muito tempo. Por duas razões muito simples. A primeira o background e as aplicações existenetes.
Mas mais importante, é que não há necessidade de 64 bits para correr jogos e programas similares (office suites etc...), não interessa agora nem daqui a 10 anos. 64 bits só tem uso para Servidores de Topo (com muitas conecções simultanias) e para cálculo cientifico (em que é necessário muita memoria da stack ). Simplesmente um jogo ou um office não corre muito mais depressa por ser 64 bits.
Gostei do teu Post. Mas já existe um windows para o amd-64 chama-se 2000/XP (full 32 bits) e corre na boa. Alias o Amd-64 vai conquistar mercado por causa disso, vai permitir correr aplicações 32 bits a velocidade real. Para quem viu a ISA dele sabe que é só um processador 32 bits com umas extensões 64 bits. Ao contrario do itanium que é full 64 bits com ums "emuladores" para 32 bits.
|
| | | | | Pois. Só que x86-64 enquanto x86-64 tem por vantagem poderes manipular inteiros de 64 bits de uma só vez, IA-64 (assim como as ISAs RISC 64 bits que por ai andam) é capaz de manipular 64 bits de dados de uma vez. Qual a diferença? É simples. Se eu quiser manipular inteiros de 32 bits, em x86-64 vou continuar a só poder manipular um de cada vez, deixando metade do data path de 64 bits às moscas. Não ganho nada em relação a x86.
Mas em IA-64 e Cª, posso usar o data path de 64 bits para manipular 2 inteiros de 32 bits de uma vez. Ou 4 de 16. Ou 8 de 8 bits.
É de por àgua na boca, não?
Como tu disseste, usar inteiros de 64 bits é, frequentemente, um exagero. Embora o tamanha de int seja vago, quando escolhemos int para tamanho de uma variàvel, estamos a pensar num número de 32 bits. Se precisamos de mais, escolhemos long int. Logo, faz parte das especificações de IA-64 (e Cª tb) ABIs em que int tem 32 bits e long int 64.
E para floats de 32 bit vale o mesmo. Claro que o Windows corre mas ai o x86-64 é igualzinho ao x86. Acabei de olhar melhor para as specs e afinal os GPRs de 64 bits só estão disponíveis em long mode, o que requer um OS criado para x86-64. Em x86, é possivel fazer cálculos com instruções de 32 bits mesmo em modo real (desde que se tenha um 386 é claro). Estava à espera de algo análogo em x86-64. UHUH... x86 vai continuar a rular.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | > Mas em IA-64 e Cª, posso usar o data path de 64 bits para manipular 2 inteiros de 32 bits de uma vez. Ou 4 de 16. Ou 8 de 8 bits.
É de por àgua na boca, não?
Excepto se o compilador decidir alinhar tudo a 64b, que é QUASE SEMPRE. Tás a fazer confusão com o multivec não ?
> Embora o tamanha de int seja vago, quando escolhemos int para tamanho de uma variàvel, estamos a pensar num número de 32 bits.
Não. Estamos a pensar em variáveis entre 0 e UINT_MAX ou INT_MIN e INT_MAX. Se estamos a pensar '32 bits' e escrevemos 'int' somos uns idiotas que alguém vai amaldiçoar no futuro. Se estamos a pensar '32 bits' escrevemos 'uint32_t'.
> Acabei de olhar melhor para as specs e afinal os GPRs de 64 bits só estão disponíveis em long mode, o que requer um OS criado para x86-64. Em x86, é possivel fazer cálculos com instruções de 32 bits mesmo em modo real (desde que se tenha um 386 é claro).
Ah, o proverbial problema do traseiro e das calças.
|
| | | | | Excepto se o compilador decidir alinhar tudo a 64b, que é QUASE SEMPRE. Tás a fazer confusão com o multivec não ? E tu estás a confundir com não sei bem o quê. IA-64 é uma ISA load/store. Ou seja, as únicas intruçõs que acedem à memória são as de load e store. Não se efectuam operações sobre o conteúdo da memória directamente. Os dados têm de ser carregados para registos. Ou seja, não interessa como estão alinhados em memoria.
Por outro lado, os dados são alinhados a min(data_size, bus_width). Logo, só os dados com 64 bits ou mais é que são alinhados a 64 bits (ou mais). Não. Estamos a pensar em variáveis entre 0 e UINT_MAX ou INT_MIN e INT_MAX. Se estamos a pensar '32 bits' e escrevemos 'int' somos uns idiotas que alguém vai amaldiçoar no futuro. Se estamos a pensar '32 bits' escrevemos 'uint32_t'. Absolutamente correcto. Ah, o proverbial problema do traseiro e das calças. Apenas o proverbial problema de, se não tiveres um OS que suporte o 64 bit mode, teres ou não os registos e data path de 64 bits é igual ao litro. Ou melhor, a um chip que suporte apenas x86.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | > No mercado high-end a questão parece clara: IA-64 or bust. Ou seja, IA-64 ou ficam como estão. Os fabricantes não irão trocar os processadores RISC que usam por x86-64 nem x86-64 tira partido da lo) nem pretendem abandorar completamente as suas arquitecturas RISC actuais em favor de IA-64.
Bust.
O HP tem alguma hipotese, o Itanium v1 é um nado morto. Atrasado, recortado, estupidamente caro. Até a Intel já viu isso, mudou o discurso "32 bits está morto, x86 64bits é uma estupidez"
> Primeiro, os processadores x86-64 vão continuar a arrancar em modo real, como se faz desde os 8086 para garantir 100% de compatibilidade com x86.
Tas a planear correr dos ?
> Além do mais, mesmo em código gerado para x86-64 vai haver a necessidade de manipular blocos de dados com menos de 64 bits. E tal como se fez em x86, isto é feito usando registos parciais. Logo, não há razões para remover suporte a 32 bits.
Compreendes que isto é válido para qualquer processador ?
|
| | | | | >> Primeiro, os processadores x86-64 vão continuar a arrancar em modo real, como se faz desde os 8086 para garantir 100% de compatibilidade com x86. >Tas a planear correr dos ? Estou! E mais uma porrada se SOs que esperam um processador em modo real. Para não falar na BIOS dos PCs. A ideia é que x86-64 seja um drop in, capaz de arrancar qq OS x86, principalmente o Windows. >>Além do mais, mesmo em código gerado para x86-64 vai haver a necessidade de manipular blocos de dados com menos de 64 bits. E tal como se fez em x86, isto é feito usando registos parciais. Logo, não há razões para remover suporte a 32 bits >Compreendes que isto é válido para qualquer processador ? Nunca vi um CPU RISC com registos parciais. Há melhores maneiras de lidar com dados menores que word.
De qualquer maneira, nem os RISC de 64 bits se esqueceram os pais de 32 (os que os têm). Compatibilidade é boa.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | > Estou! E mais uma porrada se SOs que esperam um processador em modo real. Para não falar na BIOS dos PCs. A ideia é que x86-64 seja um drop in, capaz de arrancar qq OS x86, principalmente o Windows.
AH! Li o comentário original como um critica
> Nunca vi um CPU RISC com registos parciais. Há melhores maneiras de lidar com dados menores que word.
De qualquer maneira, nem os RISC de 64 bits se esqueceram os pais de 32 (os que os têm). Compatibilidade é boa.
Ok, lê de volta "mesmo em código gerado para x86-64 vai haver a necessidade de manipular blocos de dados com menos de 64 bits. E tal como se fez em x86, isto é feito usando registos parciais."
Em modo Long tratas dados de 32 bits como em qualquer outro processador de 64 bits, não tem *nada* a ver com o suporte de 32 bits. Em modo x86-64 *só* tens registos de 64 bits.
|
| | | | Tens os registos de 64 bits e as suas partes de 32, 16 e 8.
Isto funciona assim, top down:
rax é um registo de 64 bits.
eax é um registo e 32 bits que coincide com os primeiros 32 bits de rax.
ax é um registo de 16 bits que coincide com os primeiros 16 bits de eax.
ah é um registo de 8 bits que coincide com os bits 8-15 de ax.
al é um registo de 8 bits que coicide com os primeiros 8 bits de ax.
A isto chamamos registos parciais, porque são na verdade partes de outros registos. Historicamente tinhamos o ax, ah, e al no 8086, com o 386 foi expandido para eax e com x86-64 vai ser expandido para rax. O mesmo se diz para os bx, cx e dx. A manipulação de dados em x86 (e x86-64) baseia-se na utilização destes registos parciais como operandos em instruções que manipulam apenas a quantidade de dados correspondente. O que o CrLf pensou (erradamente) é que os novos GPRs não tinham os respectivos registos parciais. Logo, não poderiam ser utilizados como operandos na manipulação de blocos de dados com 32, 16 ou 8 bits. Isto seria uma grave limitação à utilidade desses novos registos. Os processadores RISC que por ai andam não usam muito este tipo de método (sei que a FPU dos MIPS, pelo menos os de 32bits, usa algo semelhante) porque não é a melhor maneira de usar o data path.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | Bom comentario -- concordo plenamente. A vantagem que o Itanium tem sobre o Hammer da AMD e' que existem outros vendors que estao a apoiar o CPU com a transicao de sistemas operativos que nao Win32 e Linux -- e.g., a HP com o HP-UX. Estes no entanto sao um bocado uma gota no oceano, e neste caso o Linux provavelmente vai-se tornar o SO UNIX de facto para processadores de 64 bits compativeis com Intel.
Regards,
-- "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias |
| |
|
