Compilação cruzada.

[mastk]

Questão de conceito:

Era uma vez a época em que os sistemas linux embarcados eram fracos e limitados, com poucos recursos e demorava muito para compilar os programas no próprio alvo, para resolver isso usava-se a compilação cruzada, ou seja, em um PC x86 potente, de forma rápida e gerava-se o executável para o alvo definindo os paramentos do compilador.

Hoje porem, ao que vejo, os embarcados são PC completos, caso sejam instáveis e razoavelmente rápidos, pode-se trabalhar exclusivamente no próprio alvo, principalmente se ele possuir saída de video e capacidade de rodar interface gráficas.

Mastk gosta de simplificar.
Apensar de não ser a solução única, acho melhor trabalhar com o VI do que ficar batendo a cabeça com servidores e comunicação como NFS, vou fazer alguns testes e colocar mais questões e opiniões.
E os caros colegas, já entraram nesse cano? Como eu queria um servidor de SSH nessa placa, mas enfim, vamos bater a cabeça.

[tcpipchip]

Raramente compilei na plataforma alvo ;(

[msamsoniuk]

na real nao tem relacao alguma com a potencia do sistema:

http://wiki.netbsd.org/ports/sun2/

eh um 68010 de 10MHz e compila os proprios programas.

[mastk]

Bem colocado Sam, quase qualquer sistema hoje poderia complicar os próprios programas, porem o fabricante de kits de avaliação limitam o que pode ser feito, já vi alguns casos em que o foco do sistema era ajustar e recompilar todo o Kernel, isso sim levaria horas, mas creio que é para poucos, o que importa no meu caso e creio que da maioria do pessoal é criar aplicativos amarrados ao hardware, que pode ser feito mediante a um driver.

Entra outra questão que me deixa curioso em sistemas com Linux, é possível se fazer algo para evitar a copia do sistema?

[xultz]

Qual vantagem você vê em compilar no alvo?

[msamsoniuk]

Qual vantagem você vê em compilar no alvo?

qual a logica de ter dois computadores para fazer o trabalho de um? O.o

[xultz]

Eu tenho um carro e uma bicicleta. Tem lugares que vou de carro, tem lugares que vou de bike.
Eu tenho um computador e um device. Tem coisas que eu compilo no computador porque é mais rápido, tem coisas que é mais prático rodar no device.

A menos que você tenha somente o device, mas acho que esse não é o caso.

[msamsoniuk]

Eu tenho um carro e uma bicicleta. Tem lugares que vou de carro, tem lugares que vou de bike.
Eu tenho um computador e um device. Tem coisas que eu compilo no computador porque é mais rápido, tem coisas que é mais prático rodar no device.

A menos que você tenha somente o device, mas acho que esse não é o caso.

mas que analogia sem nexo xuxu! para comeco de conversa, vc sabe a diferenca entre o que vc chama de "computador" e "device"? vc sabe de onde surgiu essa pratica de nao rodar compiladores no "device"? O.o

sim, eu estava lah na lista de mail do uclinux quando alan cox apareceu uma bela manha empunhando seu machado e chamou milhares de vikings para lutar por fama e gloria! vamos rodar o linux em um 68328 sem mmu, dizia ele... bom, a maioria morreu lutando no mar de sangue do kernel do linux e nunca chegou lah... mas alan cox conseguiu! veja, na epoca a diferenca entre "computador" e "device" nao era muito diferente de agora: de um lado do abismo havia o famigerado "mac ii", um 68020 de 16MHz com mmu, 2MB de DRAM e 160MB de HD. do outro lado havia o palm pilot, um "device" baseado no 68328 de 16MHz, 2MB de DRAM e provavelmente 2MB de FLASH. a diferenca entre "computador" e "device" era a falta de um HD e a falta de mmu. e decisoes iniciais foram tomadas: como nao havia capacidade de paginacao, nao era possivel criar um mmap() do disco para a memoria, bem pq nao havia disco. portanto nao havia capacidade de carga on demand de um aplicativo. a decisao da epoca foi mapear os aplicativos diretamente na FLASH, ou seja, eles nao eram linkados on demand ou mapeados, mas compilados na sua forma final. e como vc nao escolhia exatamente onde colocar as coisas, os binarios eram compilados com saltos relativos de 16-bits em relacao ao program counter, o que limitava o tamanho dos aplicativos a +/- 32KB no 68328. uma vantagem, se for imaginar que haviam apenas 2MB de FLASH no "device", em contraste com os 160MB de HD de um "computador". bom, o gcc definitivamente era muito maior que 32KB. e definitivamente ele inteiro nao cabia em uma FLASH de 2MB. nao quer dizer que nao seja possivel: eu consigo rodar o gcc de boa em um amiga 1200 baseado em 68020 de 16MHz, com 2MB de DRAM e HD. qual o truque? simples, o gcc nessa plataforma nao esta preso ao limite de 32KB, pq o 68020 pode fazer saltos relativos de 32-bits em relacao ao program counter. eventualmente, como nao tenho mmu no 68020, o gcc pode simplesmente crashar por falta de memoria, mas usar ateh 2MB eh nitidamente muito mais viavel que 32KB. e como eu tenho um HD no "computador", eu posso ter milhares de libs e arquivos disponiveis, coisa que nao era possivel no "device"

bom, ateh onde sei o uclinux foi o primeiro unix-like opensource a nao incluir compilador no "device" justamente em funcao dessas limitacoes... mas por favor neh: sao limitacoes de 1998 em funcao de dispositivos com muito pouca memoria FLASH, muito pouca DRAM e processadores incapazes de fazer um salto relativo maior que 16-bits! nem era realmente uma limitacao tecnologica da epoca, era uma limitacao de custo: se o cara optasse por um coldfire, por exemplo, ele jah teria um core capaz de fazer saltos relativos de 32-bits. a limitacao seria entao da capacidade da FLASH, mas se ele trocasse o esquema de binario pre-linkado por um binario elf com bibliotecas dinamicas, como se usa em um "computador", entao poderia ter GBs disponiveis em cartoes MMC ou via NFS. ora! mas hoje em dia todos fazem isso, pq nao sao bobos... mas por algum motivo continuam bobos e precisam de um computador extra para compilar as coisas? no amiga 1200 com 68020 de 16MHz e 2MB de DRAM eu compilo local, no centris com 68040 de 25MHz e 64MB de DRAM eu compilo local pq sao maquinas pre-uclinux e na era pre-uclinux as maquinas compilavam tudo nelas mesmas... entao pq diabos eu nao compilo local no ipad com dual-A6 de 1GHz e 1GB de DDR? a retirada do compilador em 1998 teve uma justificativa tecnica e demoraram anos convencendo as pessoas que nao dava para rodar gcc naquela situacao... mas a situacao foi contornada faz anos e agora as pessoas ficaram grudadas naquele conceito temporario de ter que desenvolver usando uma maquina x86...mas faz algum sentido? obvio que nao. as pessoas simplesmente sao muito idiotas, demoram para entender as coisas e, quando finalmente entendem, passou tanto tempo que aquilo que queriamos que as pessoas entendessem jah eh passado e nem faz mais sentido.

agora pense bem: se vc tivesse uma bike que pesa como uma bike, custa o preco de uma bike, mas te fornece a seguranca e velocidade de um carro, com qual deles vc andaria? O.o

[tcpipchip]

Nao seriam bilotecas estaticas ?

[msamsoniuk]

Nao seriam bilotecas estaticas ?

onde?

[xultz]

1998 deve ter sido mesmo emocionante, mas vamos voltar a 2013. Ou 2014, se você estiver lendo isso depois de amanhã
Eu tenho comigo uma placa Beagleboard, com processador OMAP, 256M de RAM, 2M de Nand, e 1G de flash, tem saída HDMI pprá ligar na TV e entrada USB prá mouse e teclado. É o que eu chamo de device. É aproximadamente trocentas e vinte e quinze vezes mais potente que o computador que eu usava em 1998 e acreditava naquela conversa que o Slackware era a melhor distro Linux e que era cool passar uma semana brigando com o XF86Config prá entrar no X. Porém, estou escrevendo este post em um notebook core i7 com 4G de ram. Eu posso rodar uma distro inteira no meu device e compilar a P**** toda nele? Obviamente que sim. Se eu compilar no i7 vai ser bem mais rápido que compilar no OMAP? Claro que vai. Qual é a **** vantagem de compilar a P**** toda no OMAP, além de dizer que é possível?

[msamsoniuk]

1998 deve ter sido mesmo emocionante, mas vamos voltar a 2013. Ou 2014, se você estiver lendo isso depois de amanhã
Eu tenho comigo uma placa Beagleboard, com processador OMAP, 256M de RAM, 2M de Nand, e 1G de flash, tem saída HDMI pprá ligar na TV e entrada USB prá mouse e teclado. É o que eu chamo de device. É aproximadamente trocentas e vinte e quinze vezes mais potente que o computador que eu usava em 1998 e acreditava naquela conversa que o Slackware era a melhor distro Linux e que era cool passar uma semana brigando com o XF86Config prá entrar no X. Porém, estou escrevendo este post em um notebook core i7 com 4G de ram. Eu posso rodar uma distro inteira no meu device e compilar a P**** toda nele? Obviamente que sim. Se eu compilar no i7 vai ser bem mais rápido que compilar no OMAP? Claro que vai. Qual é a **** vantagem de compilar a P**** toda no OMAP, além de dizer que é possível?

para 8 entre 10 desenvolvedores em 2014 ter um i7 com 4GB de ram resulta nisso ae embaixo:

c:\windows> make
no such file or program 'make'.
c:\windows> _

os outros dois caras se dividem no cara que teve a brilhante sacada de instalar cygwin e no cara q tem linux na maquina.

bom, eu acho dificil o cara conseguir compilar as coisas no cygwin. primeiro pq o cara vai ter um **** trampo para montar o ambiente e o ambiente vai ser sempre uma bosta. segundo que se o linux nao compila em um bsd (q eh um milhao de vezes mais compativel com linux q windows), eu acho realmente dificil imaginar que o linux vah compilar em um windows. terceiro que adaptar a libc para as syscalls do windows nao torna o windows menor pior: provavelmente vai demorar mais compilar o negocio no i7 com cygwin do que no "device". daih sobra o cara que tem o linux na maquina. e olha, eh bem raro encontrar isso, pq convenhamos, o linux eh uma bosta de sistema operacional. as pessoas q eu conheco que usam linux em tempo integral falam noruegues arcaico e abrem caminho na rua com um machado. eh mais provavel que o cara tenha um dual-boot ou uma maquina virtual. no primeiro caso o cara tem o incomodo de rebootar a maquina e sofrer com um linux que provavelmente esta meio abandonado e malemal funciona: o cara digita make e dah crash pq fez update da libc, mas nao fez update do resto... no segundo caso o cara coloca um linux inteiro em cima de um windows e, como era de se esperar, fica uma bosta. em todos os casos o i7 com 4GB vira um 386 com 256MB de ram, no aspecto que demora, dah trabalho e eh bastante frustrante... nao, eu nao estou de zueira, antes fosse, na real eh muito tragico pq eh o que eu observo no dia a dia da galera que trabalha com linux embarcado em outros sistemas! +_+

e olha que os caras que usam linux no device estao na vantagem: tem uma porrada de servers parrudos rodando linux com os cross-compilers prontinhos lah para usar via ssh. triste mesmo eh a vida dos caras que nao usam linux no device e precisam manter um solaris ou hpux vivo na rede para usar um cross-compiler legado. mas nao... realmente triste sao os caras q eu conheci que precisavam jogar pessoas em vulcoes para manter usar um cross-compilar em um VAX da decada de 80! +_+

entao pq desperdicar entao o OMAP que esta ali parado na sua estante e tem um linux funcionando em tempo integral?

e bom, alguns anos atras eu nem diria que o device ser melhor que um computador nao era de forma alguma fora de questao: o meu antigo notebook core2duo de 2GHz realmente era *mais lento* que uma devel board com um P2020 de 1GHz por um fator de 30% (obrigado intel por generosamente compartilhar sua mediocridade no projeto de computadores*). hoje em dia eu tenho um i5 de 2.5GHz que bate o P2020 de lavada... mas perde para um P4080 de 1.5GHz por um fator de apenas 100%! hahaha nossa, olha a ideia de marketing que eu pensei: INtel+eVOLUCAO = INVOLUCAO? sem bem que eu acho que a intel bate tranquilo um ARM, afinal, se os caras perderem para o ARM, eles vao empatar com quem? (:

* para saber mais sobre a habilidade da intel no projeto de processadores: http://en.wikipedia.org/wiki/Intel_iAPX_432

[vtrx]

Não é por nada não,mas usar WIKIPEDIA como referencia...
Eu mesmo alterei a primeira linha,qualquer um poe oque quer.

[msamsoniuk]

Não é por nada não,mas usar WIKIPEDIA como referencia...
Eu mesmo alterei a primeira linha,qualquer um poe oque quer.

tah, e que tal essas referencias entao? nem olhei no wikipedia desta vez.

Books

[Organick, 1983]. Elliott Organick, A Programmer's View of the Intel 432 System, McGraw-Hill, New York, N.Y., 1983.
Myers, Glenford J., Advances in Computer Architecture, 2nd Edition, John Wiley & Sons, New York, N.Y., 1982, pp. 335-340, 344, 366, 371
Levy, Henry M., Capability-Based Computer Systems, Digital Press, 1984

Papers

Justin R. Rattner, William W. Lattin: "Ada Determines Architecture of 32-bit Microprocessor," Electronics, Vol 4 No 54, 24 February 1981, pp. 119-126
Justin R. Rattner: "Hardware/Software Cooperation in the iAPX-432," Proceedings of the Symposium on Architectural Support For Programming Languages and Operating Systems, March 1-3, 1982: p. 1
Fred J. Pollack, George W. Cox, Dan W. Hammerstrom, Kevin C. Kahn, Konrad K. Lai, Justin R. Rattner: "Supporting Ada Memory Management in the iAPX-432," Proceedings of the Symposium on Architectural Support For Programming Languages and Operating Systems, March 1-3, 1982: pp. 117-131
George W. Cox, William M. Corwin, Konrad K. Lai, Fred J. Pollack: "A Unified Model and Implementation for Interprocess Communication in a Multiprocessor Environment," Proceedings of the Eighth Symposium on Operating System Principles, 14-16 December 1981, pp. 125-126
Kevin C. Kahn: "A Small-Scale Operating System Foundation for Microprocessor Applications," Proceedings of the IEEE, Vol. 66 No. 2, February 1978
Kevin C. Kahn, William M. Corwin, T. Don Dennis, Herman D'Hooge, David E. Hubka, Linda A. Hutchins, John T. Montague, Fred J. Pollack "iMAX: A Multiprocessor Operating System for an Object-Based Computer," Proceedings of the Eighth Symposium on Operating System Principles, 14-16 December 1981, pp. 127-136
Kevin C. Kahn, Fred J. Pollack: "An Extensible Operating System for the Intel 432," Proceedings Compcon Spring 1981, February 1981, pp. 398-404
Fred J. Pollack, Kevin C. Kahn, Roy M. Wilkinsom: "The iMAX-432 Object Filing System," Proceedings of the Eighth Symposium on Operating System Principles, 14-16 December 1981, pp. 137-147
Kevin C. Kahn: "Object-Oriented Languages Tackle Massive Programming Headaches," Electronics, 17 November 1982
George W. Cox, William M. Corwin, Konrad K. Lai, Fred J. Pollack: "Interprocess Communication and Processor Dispatching on the Intel 432," ACM Transactions on Computer Systems, Volume 1, Number 1, February 1983 pp 45-66
S. Zeigler, N. Allegre, R Johnson, J. Morris, "Ada for the Intel 432 Microcomputer," IEEE Computer, Vol. 14 Number 6, June 1981, pp. 47-56
S. Ziegler, N. Allegre, D. Coar, R. Johnson, J. Morris, G. Burns: "The Intel 432 Ada Programming Environment," Proceedings Compcon Spring 1981, February 1981, pp. 405-410
R. Johnson: "The Intel iAPX-432: An Architecture for Ada," Proceedings of the Symposium on High-Level Computer Architecture, October 1981
D. Johnson: "The Intel 432: a VLSI Architecture for fault-tolerant computer systems.", Computer, New York, 17(8):40-48, Aug. 1984
Colley et al, "The object-based architecture of the Intel 432, CbMPCON (Feb. 1981)
R. Ebersole: "Designing a High-Performance Bus for a Multiprocessor System," Phoenix Conference on Computers and Communications, May 1982
D. Kinder: "Transparent Multiprocessing Boosts µC Throughput," Electronic Design News, April 15, 1982
D. Kinder: "Ada, iMAX, and Intel's iAPX 432," Annual Conference Proceedings for Associazione Italiana Per Il Calcolo Automatico, October 1982
M.J. McGowan: "The Information Management Capabilities of the iAPX 432 Processor," Computer Technology Review, Summer 1982
R. Kaiser: "The 432 Micromainframe Architecture," Proceedings of the 35th Conference of the American Institute of Aeronautics and Aerospace, September 1981
H.I. Jacob: "An Architecture for the 80's--The Intel iAPX-432," Proceedings of Midcon '81, November 1981
Paul M. Hansen, Mark A. Linton, Robert N. Mayo, Marguerite Murphy, and David A. Patterson: "A Performance Evaluation of the Intel iAPX 432", Computer Architecture News, June 1982.
I.H. Witten, J.G. Cleary: "An introduction to the architecture of the Intel iAPX 432," Software and Microsystems, 2(2) 29-34, April 1983
Robert P. Colwell, Edward F. Gehringer, and Doug Jensen, "Performance Effects of Architectural Complexity in the Intel 432," ACM Transactions on Computer Systems, vol. 6, no. 3, August 1988, pp. 296-339.
Edward F. Gehringer and Robert P. Colwell, "Fast Object-Oriented Procedure Calls: Lessons From the Intel 432," 13th Annual Symposium on Computer Architecture, Tokyo, 1986, pp. 92-101.
K. U. Hellmold: Modell zur Simulation eines Multiprozessorsystems auf der Basis von Intel Prozessoren - IAPX432 und einem Kreuzschienenverteiler für die Speicherkopplung, Messung, Modellierung und Bewertung von Rechensystemen (MMB), 2. GI/NTG-Fachtagung, Stuttgart, 21.-23. February 1983, pp. 366-381
Xiao-Zong Yang, Gary York, William P. Birmingham, Daniel P. Siewiorek: "Fault Recovery of Triplicated Software on the Intel iAPX 432," Proceeding of the 5th International Conference on Distributed Computing Systems, Denver, Colorado, May 13-17, 1985, IEEE-CS Press, 1985, ISBN 0-8186-0617-7 pp. 438-443
Guy Almes, A. Borning, and E. Messinger: "Implementing a Smalltalk-80 system on the Intel 432," In Krasner [Smalltalk-Bits of History, Words of Advice], pages 175-187.
R. Fabry, "Capabiltiy Based Addressing," Communications of the ACM Vol. 17, 1974, pages 403-412.
L. Ciminiera, A. Valenzano: "Efficient Authentication Mechanisms Using the iAPX-432," Interfaces in Computing, Vol. 3, 1985, pp. 111-124
L. Ciminiera, A. Valenzano: "iAPX 432 Hardware Fault-Handling Mechanisms," Software and Microsystems, Vol. 3, No. 3, June 1984, pp. 67-74
"Ada Lessons from Programming the iMAX 432 Operating System," Proceedings for the National Topical Conference on Using Ada -- A New Era in Adaptable, Reliable Software, June 1983
"Ada and the Intel iAPX 432", Proceedings for the National Topical Conference on Using Ada -- A New Era in Adaptable, Reliable Software, June 1983
Roger Alan Cooper: "Generating an out-the-window cockpit image with the iAPX 432, 1982, Air Force Institute of Technology, Wright-Patterson Air Force Base
G. Cattaneo, V. Piuri, N. Scarabottolo, F. Urero, "CHILL concurrency on Intel iAPX 432 architecture", Microprocessing and Microprogramming - The EUROMICRO Journal, North-Holland, vol. 15, n. 5, 1985, pp. 233-251
W. Hoffman, A. Lehmann, "Leistungsfähigkeit von Mehrprozessorsystemen mit iAPX 432-Prozessoren, Kreuzschienenverteiler und Pufferspeichern", Informatik-Fahbericht Nr. 78: Architektur und Betrieb von Rechen-systemen, 8, GI/NTG-Fachtagung, Springer Verlag, März 1984

Theses

Robert Paul Colwell, "The Performance Effects of Functional Migration and Architectural Complexity in Object-Oriented Systems", CMU-CS-85-159, August 1985
Dwayne Phillips, "Image Processing with the Ada Programming Language and the Intel iAPX 432 Microprocessor", Master's Thesis, Louisiana State University, December 1984

agora, se vc nao achou suficiente, vai tomar bem no meio seu c* seu chato! +_+

[vtrx]

agora, se vc nao achou suficiente, vai tomar bem no meio seu c* seu chato! +_+

Pare de chorar!