Desempenho XC8 Pro

[KrafT]

A Mxip sacaneia legal a compilação do código quando na versão Free... Já tava precisando usar um chip "mais maior"...

[xultz]

Uma vez eu vi uma análise que um cara fez, compilando alguns códigos e vendo o resultado no assembly gerado. Ele chegou à conclusão que o compilador Pro não otimiza nada, ele faz o que deve ser feito, e que a versão Free enfia um monte de tralhas inúteis no assembly prá ficar maior e mais lento.

[KrafT]

Esse cara aqui Xû?

http://www.t4f.org/articles/optimizatio ... -pro-mode/

[xultz]

Esse mesmo.

[msamsoniuk]

Uma vez eu vi uma análise que um cara fez, compilando alguns códigos e vendo o resultado no assembly gerado. Ele chegou à conclusão que o compilador Pro não otimiza nada, ele faz o que deve ser feito, e que a versão Free enfia um monte de tralhas inúteis no assembly prá ficar maior e mais lento.

isso eh genial! \o/

[Vonnilmam]

Olá a todos,

Bom, eu sou aprendiz em C, bem aprendiz mesmo...

Mas em assembler já dou umas arranhadas a muitos anos, sou da velha guarda z80 e afins.

Tô mexendo com C, por causa da modernidade das coisas, mas é justamente esse ponto que sempre me bloqueou em querer aprofundar-me em C, é a sacanagem dos compiladores (fabricantes)...
VOU CONTAR UM CAUSO...kkk
Uma certa vez, quis me aventurar em aprender mexer com os chips da ALTERA, me ofereceram na época uma licença paga, bom disseram que dava para fazer isso aquilo e tal...um dia, por acaso estava eu lá no escritório da arrow, quando vi o pessoal "brigando", o papo era o seguinte: Uma empresa iniciou pelo visto um trabalho complexo em torno do altera e como a coisa foi crescendo, o compilador ia dando PAU, ou seja, pedia que o licenciado compra-se outra licença para ter acesso a outras LIBs...e pelo que notei a empresa não estava querendo comprar mais libs, pelo que percebi, venderam uma idéia para os caras e quando os caras da empresa começaram a mandar ver no software deles e isso necessitava, maior capacidade do chip altera, era aonde o bicho pegava, o soft pedia que o licenciado compra-se novas licenças para fazer o que ele queria, salvo engano, era algo para telecomunicações.

O C é legal, facilita bastante, apesar de eu estar sofrendo para entender a lógica de programação. Mas de uma coisa eu sei, o ASM é um quebra galho daqueles.

Hà sim, na ocasião, a licença solicitada para cada lib solicitada, era de 10$mil...cada uma e os caras parece que precisariam de algumas libs destas e especial...

Isso é ví ao vivo e em cores...

[Rodrigo_P_A]

Olá a todos,

Bom, eu sou aprendiz em C, bem aprendiz mesmo...

Mas em assembler já dou umas arranhadas a muitos anos, sou da velha guarda z80 e afins.

Tô mexendo com C, por causa da modernidade das coisas, mas é justamente esse ponto que sempre me bloqueou em querer aprofundar-me em C, é a sacanagem dos compiladores (fabricantes)...
VOU CONTAR UM CAUSO...kkk
Uma certa vez, quis me aventurar em aprender mexer com os chips da ALTERA, me ofereceram na época uma licença paga, bom disseram que dava para fazer isso aquilo e tal...um dia, por acaso estava eu lá no escritório da arrow, quando vi o pessoal "brigando", o papo era o seguinte: Uma empresa iniciou pelo visto um trabalho complexo em torno do altera e como a coisa foi crescendo, o compilador ia dando PAU, ou seja, pedia que o licenciado compra-se outra licença para ter acesso a outras LIBs...e pelo que notei a empresa não estava querendo comprar mais libs, pelo que percebi, venderam uma idéia para os caras e quando os caras da empresa começaram a mandar ver no software deles e isso necessitava, maior capacidade do chip altera, era aonde o bicho pegava, o soft pedia que o licenciado compra-se novas licenças para fazer o que ele queria, salvo engano, era algo para telecomunicações.

O C é legal, facilita bastante, apesar de eu estar sofrendo para entender a lógica de programação. Mas de uma coisa eu sei, o ASM é um quebra galho daqueles.

Hà sim, na ocasião, a licença solicitada para cada lib solicitada, era de 10$mil...cada uma e os caras parece que precisariam de algumas libs destas e especial...

Isso é ví ao vivo e em cores...

Desculpe, se fosse em Assembler ele num teria que comprar pronta ou desenvolver da mesma forma?
Dá pra desenvolver qualquer coisa, ou comprar lib pronta independente da linguagem.

Enviado de meu SM-A700FD usando Tapatalk

[Vonnilmam]

Acho que não me expressei corretamente, peço desculpas.

No caso do ALTERA com o cliente em questão, o fato era além das libs específicas, também a compilação final que era limitada...salvo engano eram isso.

Sim, creio que dá para desenvolver muita coisa, via software no caso, com diversos tipos de linguagem.
Concordo plenamente.

Vejam, eu não manjo nadinha de C, apenas quis compartilhar um CAUSO que ví...kkk

[Rodrigo_P_A]

Acho que não me expressei corretamente, peço desculpas.

No caso do ALTERA com o cliente em questão, o fato era além das libs específicas, também a compilação final que era limitada...salvo engano eram isso.

Sim, creio que dá para desenvolver muita coisa, via software no caso, com diversos tipos de linguagem.
Concordo plenamente.

Vejam, eu não manjo nadinha de C, apenas quis compartilhar um CAUSO que ví...kkk

Deve ser por limitação mesmo, ou alguma coisa muito específica.

[msamsoniuk]

se vc mexe com Z80, vc deve ter cara daqueles velhinhos que levam os netinhos comer tortinha de maca no mcdonalds... e os caras estavam tentando te enganar hein! hehehe

na medida que a altera fabrica FPGAs e CPLDs, imagino que vc estava pensando em usar uma FPGA deles. tanto a altera quando a xilinx e lattice, as tres mais importantes da area, oferecem os tools totalmente de graca para as CPLDs e FPGAs menores. em tempo, esses tools nao tem relacao com linguagem C, pq as CPLDs e FPGAs sao programas em verilog e VHDL. eventualmente, daria para nao usar, mas parece impossivel: uma FPGA low-end tem uns 50 mil gates e eu chutaria que pelo menos 1/3 eh configuravel, ou seja, o esforco seria equivalente a fazer esquematico e layout de uma PCB com 15 mil componentes. melhor usar o tool deles neh. para ser necessario pagar, tem que usar uma FPGA muito grande: FPGAs grandes sao caras, sao usados por gente rica e, portanto, eh quem pode pagar... mas FPGA cara que eu estou falando sao componentes de mil dolares para aplicacoes especificas, que eu acho que nao eh o caso neh. fora isso, existe mais um detalhe: processadores. para usar processadores dentro da FPGA, vc precisa de IPs (intellectual properties) e isso custa caro, precos da ordem daqueles que vc citou. mas veja bem: estamos falando de um processador: tipo projetar um PIC e te passar a netlist do PIC, transistor por transistor... tem um custo e os caras querem cobrir isso, vc nao iria querer receber se fosse dono do PIC? ou passaria na faixa? certamente a maioria das pessoas nao faria de graca, mas se vc procurar na http://opencores.org vc tem N opcoes sem custo! alem disso tem os tolos da lattice, cujo processador mico eh sem custo, ou seja, vc poderia pegar os tools gratis da altera ou xilinx e usar o mico da lattice. tudo de gratis! nao deixe te enganarem nao! :v

mas note que absolutamente nada disso tem a ver com linguagem C... nem mesmo aqueles processadores que os caras querem cobrar para vc usar ou aqueles que a opencores e a lattice te dao de gratis. mas da mesma forma que existe a opencores e tem pessoas que projetam processadores para dar de gratis sem cobrar absolutamente nada, existem outros grupos que projetam compiladores C para dar de gratis sem cobrar absolutamente nada. e daih eu recomendaria: sdcc e gcc. existem outros grupos com seus respectivos compiladores, mas estes caras sao os mais difundidos. o gcc eh uma especie de mecca da linguagem C: o compilador eh um dos mais difundidos na comunidade unix e, na medida que o unix eh escrito em C, provavelmente eh o compilador mais popular. o sdcc, por outro lado, eh focado em pequenas arquiteturas que nao rodam unix, como pic, avr, hc08, z80, etc. eu usei bastante o sdcc com o hc08 e consegui fazer realmente bastante coisa. mas da mesma forma que eu vim lah do unix, a linguagem C tambem veio: entao quando vc, acostumado com processadores de 32-bits com capacidade multi-MIPS/multi-MBytes, cai em um processador de 8 bits com capacidades substancialmente menores, a coisa fica meio apertada. mas funciona. e no caso do sdcc, funciona e eh gratis.

experiencia propria: nas decadas em que trabalhei com processadores x86 e 68k, eu poderia ter usado as ferramentas dos fabricantes. mas nao, nunca as usei, sempre usei gcc ou sdcc. provavelmente perdi as telas bonitas e o suporte que as ferramentas pagas tinham, mas nao me arrependo. como um causo, posso contar a experiencia da empresa em que trabalho: eles usavam um compilador comercial para o 68k. como era uma grande multinacional, o custo era irrelevante. o compilador roda em sparcstations, um tipo de maquina unix da decada de 80 e 90. naquela epoca, fazia sentido, visto que o PC era um brinquedo que rodava basic, fazia beep e tinha disquetes de 300KB, ou seja, computador para criancas. enfim, o tempo passou e hoje a firma tem uma ou duas sparcstations que estao no ar faz decadas rodando o tal compilador. detalhe: se as maquinas pararem (e elas ficam mais tempo em manutencao do que funcionando), nao existem mais maquinas para trocar. a manutencao eh feita na base do canibalismo, tirando pecas das outras sparstations que jah pararam faz decadas. e o compilador soh roda nessas maquinas, nao tem como portar, nao tem versao nova, eh simplesmente sem opcao... em paralelo, na epoca em que entrei na empresa, comecamos a fazer projetos novos usando o gcc: deu um pequeno trabalho para portar a sintaxe do assembler, mas como o resto era tudo feito em C, portamos milhoes de linhas de codigo rapidamente. a questao nao era o custo: embora custe milhares de dolares a anuidade do compilador antigo e o gcc seja gratis, tem algo mais importante: o compilador antigo soh roda nas sparcstations que nem sao mais fabricadas, enquanto o gcc roda em qq maquina com linux. se o linux morrer, nao tem problema, eu tenho gcc no meu mac. se o meu mac quebrar, nao tem problema, eu baixo um freebsd da internet e rodo em qq computador. no fundo, nao eh assim tao simples, mas na teoria eh isso.

e bom, para finalizar, tem que tomar cuidado com a ideia de que linguagem C eh modernidade: longe disso. a coisa tem relacao com capacidade. quando o unix nasceu, lah no PDP7, era escrito em assembler. era um minicomputador de 18 bits com 9KB de memoria, uma arquitetura capenga que rodava a uns 0.5 MIPS e custava 72 mil dolares. eles nem tinham terminal serial como eh hoje, ao inves disso, usavam uma maquina de escrever eletrica como terminal e armazenamento em fitas de rolo:



o PDP7 era mais ou menos como programar um PIC... mas quando os caras do unix tiveram a disposicao os primeiros PDP11, as coisas melhoraram substancialmente: a maquina era 16-bits, suportava segmentacao de memoria para atingir alguns megabytes e rodava com uma performance melhor. a propria evolucao tecnologica permitiu terminais texto baseados em CRTs, discos mais velozes, etc. com mais recursos, podia-se trabalhar com aplicacoes mais complexas. mas daih jah nao fazia sentido usar assembler: por isso a linguagem C apareceu. eventualmente, ainda na decada de 70, o unix inteiro foi portado para C. e C eh uma linguagem que escala bem para grandes niveis de complexidade: da mesma forma que o unix rodava bem no PDP11, ele roda hoje no coracao de cada iphone e ipad que vc encontra por aih. entao programar em C nao eh ser moderno, longe disso, eh poder trabalhar com coisas mais complexas.

mais ainda, nao existe uma relacao direta entre nivel da linguagem e complexidade: assembler eh muito baixo nivel, mas a linguagem tem baixo suporte estrutural, o que nao te permite fazer coisas muito complexas. C eh uma linguagem levemente de melhor nivel. eh mais simples que assembler, mas nitidamente mais complicada do que qq outra linguagem. para fazer algo simples, vc pena. para fazer algo complexo, entao, pena mais ainda. mas tem estrutura para fazer e eh por isso que se projeta sistemas operacionais nela. daih vc pega uma linguagem tipo java ou pascal: possuem nivel bem superior em relacao a C e asm, de modo q algo simples eh simples de fazer. algo complicado, como um sistema operacional, pode simplesmente nao ser possivel. entao o forte de C eh complexidade... de fato, C rodando no unix eh como um porco no chiqueiro, porem C rodando fora do unix eh como o porco no seu quintal. funciona, mas eh meio complicado. bom, nao foi uma boa analogia, mas achei engracada e vai ficar essa mesmo! o/ hehehe

Olá a todos,

Bom, eu sou aprendiz em C, bem aprendiz mesmo...

Mas em assembler já dou umas arranhadas a muitos anos, sou da velha guarda z80 e afins.

Tô mexendo com C, por causa da modernidade das coisas, mas é justamente esse ponto que sempre me bloqueou em querer aprofundar-me em C, é a sacanagem dos compiladores (fabricantes)...
VOU CONTAR UM CAUSO...kkk
Uma certa vez, quis me aventurar em aprender mexer com os chips da ALTERA, me ofereceram na época uma licença paga, bom disseram que dava para fazer isso aquilo e tal...um dia, por acaso estava eu lá no escritório da arrow, quando vi o pessoal "brigando", o papo era o seguinte: Uma empresa iniciou pelo visto um trabalho complexo em torno do altera e como a coisa foi crescendo, o compilador ia dando PAU, ou seja, pedia que o licenciado compra-se outra licença para ter acesso a outras LIBs...e pelo que notei a empresa não estava querendo comprar mais libs, pelo que percebi, venderam uma idéia para os caras e quando os caras da empresa começaram a mandar ver no software deles e isso necessitava, maior capacidade do chip altera, era aonde o bicho pegava, o soft pedia que o licenciado compra-se novas licenças para fazer o que ele queria, salvo engano, era algo para telecomunicações.

O C é legal, facilita bastante, apesar de eu estar sofrendo para entender a lógica de programação. Mas de uma coisa eu sei, o ASM é um quebra galho daqueles.

Hà sim, na ocasião, a licença solicitada para cada lib solicitada, era de 10$mil...cada uma e os caras parece que precisariam de algumas libs destas e especial...

Isso é ví ao vivo e em cores...

[Vonnilmam]

Com todo o respeito, **** QUE LÁ PUTS...

O msamsoniuk, deu uma aula no veio vonnilmam...

Coitado de mim...vixxi...

Então, só para entender e não sair fora do foco (senão o moderador briga conosco), eu nem me atrevo em brincar com lógica programável...a situação aconteceu e eu estava presente na arrow, tanto que depois dessa cai fora de fpga, não era para mim.

Eu tento programar em assembler a uns 25 anos, mas é só brincadeira de criança...o veio z80 era e ainda acho que é um cara muito interessante, apesar de gostar do 8051 arquitetura, hoje em dia, brinco pouco, com os pics e atmega da vida...
Acho o C legar, como você disse, acho também complicada a forma de compreensão da lógica de programação no C, percebo ser bem diferente do ASM (me refiro ao raciocínio).
Diferentemente o BASIC, já me dou melhor, consigo "visualizar" melhor a lógica.

A explicação do chiqueiro foi CHIQui.


Gostei da explanação sobre as linguagens, foi muito boa, parabéns...

Obrigado a todos.

[pamv]

Ei!
Eu usei essas tty33 para acessar um PDP10 rodando TOPS-10 (um OS que não tinha o conceito de subdiretório), elas davam choque em algumas partes se não estivessem bem aterradas.
A vantagem delas era a leitora/perfuradora de fita de papel, dava para gravar um arquivo na fita e depois subi-lo de volta pro dec10 onde disco era uma coisa preciosa.

Sobre o C aqui no Brasil: ele demorou para aparecer no varejo, eu fiz meu curso de programação em Fortran em um mainframe B6700 com cartão perfurado e depois outro curso em Basic, na época ainda tinha a opção por COBOL e Algol e a profa da computação apostava todas a fichas no Pascal, inclusive lançou um livro na época. Sobre C eu tomei conhecimento na Byte, que era excelente na época e não 100% orientada a "Wintel"

O primeiro acesso a C na prática apareceu no início dos anos 80 com os microprocessadores baseados em Z80/8085 com floppy disk mas não tinha muita vantagem em ambiente CP/M sobre o fortran para quem fazia calculeira e estava portando do Mainframe pro PC. Depois, apareceu o turbo pascal e dominou o cenário de desenvolvimento de programas ficando o fortran para os ports de mainframe->microcomputadores.

Unix na época, até onde eu lembro, era pirataria da Edisa e da Marinha e de acesso muito restrito e não acadêmico, um amigo que fez computação na UFRJ teve acesso
e trabalhou com C no Unix da Marinha e isso valeu um bom emprego no exterior naquela época que todo mundo migrava fugindo da crise, mas ele foi exceção.

O C decolou depois do fim da reserva de mercado e outras restrições (tipo ter que assinar uma declaração pros EUA que eu não ia fabricar uma bomba atômica com a workstation) que evitavam a entrada do Unix, com a chegada das Suns, SGI, HP, etc o C decolou forte e o gcc junto com ele.
O forte do C é o que o Marcelo destacou: uma linguagem simples e ao mesmo tempo capaz de lidar com complexidade, na época o fraco era a falta de padronização, cada fabricante tinha o seu C e portar de um "unix" para outro, mesmo com gcc, era dureza, tanto que os gnus inventaram o configure e cia.

Quanto ao xc8, eu estou começando com ele este ano e uma das idéias que eu tinha era lá na frente analisar o assembler que a versão free gera e ver possíveis otimizações, pelo que vocês falaram, não vou deixar pra ver lá na frente ele dá calote no tamanho e na eficiência do código.

Queria aproveitar pra fazer uma pergunta sobre o xc8, como o eu defino o load address do executável? No mikroC eu defino, p.ex.

#pragma orgall 0x1000

mas no xc8 eu não achei uma resposta definitiva lendo o manual ou buscando nos foruns da microchip

[andre_luis]

Queria aproveitar pra fazer uma pergunta sobre o xc8, como o eu defino o load address do executável? No mikroC eu defino, p.ex.

#pragma orgall 0x1000

mas no xc8 eu não achei uma resposta definitiva lendo o manual ou buscando nos foruns da microchip

Meu palpite é porque de certo modo em C não tem muita utilidade pratica em se definir um endereço absoluto, o compilador já se encarrega disso, e aparentemente uma definição do programador poderia entrar em conflito com a o linker...acho eu.

[pamv]

Queria aproveitar pra fazer uma pergunta sobre o xc8, como o eu defino o load address do executável? No mikroC eu defino, p.ex.

#pragma orgall 0x1000

mas no xc8 eu não achei uma resposta definitiva lendo o manual ou buscando nos foruns da microchip

Meu palpite é porque de certo modo em C não tem muita utilidade pratica em se definir um endereço absoluto, o compilador já se encarrega disso, e aparentemente uma definição do programador poderia entrar em conflito com a o linker...acho eu.

você está correto, mas nesse caso é necessidade de uma placa com 18F4550 que tem o bootloader acima desse endereço e com o mikroC eu posso compilar o código independente de endereço e carrega-lo após o bootloader

[msamsoniuk]

que legal meo! eu li isso e quase chorei aqui!

fiquei imaginando vc tipo o gandalf contando suas aventuras na terra media da digital equipment corporation! \o/



nessa epoca ae que vc falou eu ainda era garoto e curtia mesmo era andar de bike! mas tb curtia brincar com eletronica: comecei com aquelas revistas de projetinhos basicos e fui evoluindo. nesta epoca eu vi que eletronica analogica nao tinha muito futuro: as coisas nao funcionavam direito! isso quando funcionavam... comecei a brincar mais e mais com logica digital e pintei e bordei ligando tralhas nas paralelas dos computadores hahaha software, nessa epoca, soh assembler neh... aprendi, sucessivamente, assembler para o Z80, 8086 e 68000. lembro bem pouco da epoca, mas lembro dos dias e dias que passei tentando acessar o floppy disk do msx diretamente em assembler hehehe mas quando entrei na faculdade, precisava usar muito computadores para fazer calculos, entao parti para a linguagem C e a eletronica ficou totalmente de lado. por sinal, esse eh um ponto que eu vejo que todo mundo passa: quando vc aprende C, se vc for pelo caminho tradicional, vc quebra a cara. o fato eh que C nao funciona muito bem fora do unix. entao nessa epoca eu entrei em panico: precisava do unix no PC. pensei ateh em comprar um unix para rodar no PC, mas foi entao que um professor da ufpr me passou uma sacola com o slackware 2.0, que era instalado a partir de 70 disquetes de 3.5". esse fato orientou a minha carreira para o lado do TI por muitos e muitos anos, ateh que em um dado momento da minha vida eu cansei de sofrer e resolvi voltar para a area de desenvolvimento. primeiro como uma atividade paralela (eu vendia microcontroladores HC908GR4 para a galera aqui do forum), depois acabei largando de vez a area de TI e hoje soh trabalho com eletronica digital (verilog), mantendo uma distancia segura das coisas que tenho medo: TI, software e eletronica analogica! :v hahaha

sobre o que vc quer fazer em C, a dica que eu daria eh vc procurar no seu compilador como criar um arquivo de linker ou passar por parametro! em pelo menos 9 entre 10 compiladores que eu conheci, o processo de compilacao consistia em compilar o .c para gerar o arquivo .o, que era linkado pelo linker. o linker, por sua vez, abria um arquivo onde havia uma descricao com o layout da memoria, de modo que vc podia posicionar os respectivos modulos .o arbitrariamente no espaco de memoria. aqui tem um exemplo para o PIC:

http://electronics.stackexchange.com/questions/129652/microchips-xc8-linker-doesnt-recognize-some-custom-section-names

eu francamente nao entendo muito bem o pq de posicionar em pontos diferentes da memoria pq nao conheco a arquitetura do PIC.

no compilador sdcc para o hc08, eu usava um mecanismo diferente, via opcao na ferramenta:

webcache.googleusercontent.com/search?q=cache:W-D-8x3cgqAJ:framework.sourceforge.net/pics/hc908rtos/branches/0/0/1/Makefile+&cd=2&hl=en&ct=clnk&gl=br&client=safari

nesta arquiteutura o IO e ram comecam sempre no mesmo lugar, porem conforme o modelo do microcontrolador vc precisa indicar onde fica a flash e qual o tamanho da ram. no caso, o comeco da flash seria em 0xEE00 e a stack em 0x1BF define o limite maximo da ram.

Ei!
Eu usei essas tty33 para acessar um PDP10 rodando TOPS-10 (um OS que não tinha o conceito de subdiretório), elas davam choque em algumas partes se não estivessem bem aterradas.
A vantagem delas era a leitora/perfuradora de fita de papel, dava para gravar um arquivo na fita e depois subi-lo de volta pro dec10 onde disco era uma coisa preciosa.

Sobre o C aqui no Brasil: ele demorou para aparecer no varejo, eu fiz meu curso de programação em Fortran em um mainframe B6700 com cartão perfurado e depois outro curso em Basic, na época ainda tinha a opção por COBOL e Algol e a profa da computação apostava todas a fichas no Pascal, inclusive lançou um livro na época. Sobre C eu tomei conhecimento na Byte, que era excelente na época e não 100% orientada a "Wintel"

O primeiro acesso a C na prática apareceu no início dos anos 80 com os microprocessadores baseados em Z80/8085 com floppy disk mas não tinha muita vantagem em ambiente CP/M sobre o fortran para quem fazia calculeira e estava portando do Mainframe pro PC. Depois, apareceu o turbo pascal e dominou o cenário de desenvolvimento de programas ficando o fortran para os ports de mainframe->microcomputadores.

Unix na época, até onde eu lembro, era pirataria da Edisa e da Marinha e de acesso muito restrito e não acadêmico, um amigo que fez computação na UFRJ teve acesso
e trabalhou com C no Unix da Marinha e isso valeu um bom emprego no exterior naquela época que todo mundo migrava fugindo da crise, mas ele foi exceção.

O C decolou depois do fim da reserva de mercado e outras restrições (tipo ter que assinar uma declaração pros EUA que eu não ia fabricar uma bomba atômica com a workstation) que evitavam a entrada do Unix, com a chegada das Suns, SGI, HP, etc o C decolou forte e o gcc junto com ele.
O forte do C é o que o Marcelo destacou: uma linguagem simples e ao mesmo tempo capaz de lidar com complexidade, na época o fraco era a falta de padronização, cada fabricante tinha o seu C e portar de um "unix" para outro, mesmo com gcc, era dureza, tanto que os gnus inventaram o configure e cia.

Quanto ao xc8, eu estou começando com ele este ano e uma das idéias que eu tinha era lá na frente analisar o assembler que a versão free gera e ver possíveis otimizações, pelo que vocês falaram, não vou deixar pra ver lá na frente ele dá calote no tamanho e na eficiência do código.

Queria aproveitar pra fazer uma pergunta sobre o xc8, como o eu defino o load address do executável? No mikroC eu defino, p.ex.

#pragma orgall 0x1000

mas no xc8 eu não achei uma resposta definitiva lendo o manual ou buscando nos foruns da microchip