Newsgroup: it.hobby.elettronica.digitale
Titolo: Programmazione nell'elettronica digitale

Salve,
Forse la mia domanda č troppo generica ma nell'ambito dell'elettronica 
digitale, in particolare per quanto riguarda i sistemi embedded, PIC, etc.. 
quali sono i linguaggi piů utilizzati? Mi pare siano il C e l'assembly ma 
per caso c'e' modo di usare anche Java o Python per tali scopi? 

 per caso c'e' modo di usare anche Java o Python per tali scopi? 
Anche se ci fossero io personalmente li sconsiglierei per raggioni 
legati alla prestazioni. Che è sta mania di mettere Java dapertutto? 
Cosa ha il C a non andare? Ci puoi fare tutto quello che vuoi, con il 
Java no...
-- 
Il Razziatore,
"Lo sviluppo di una nazione si misura anche dallo stato della sua rete 
ferroviaria". Camillo Benso Conte di Cavour
"Per tutto quanto non previsto nel presente regolamento il capostazione 
deve usare senno e ponderatezza." Regolamento d'esercizio FS
-----------------------------------------------
MSN   : 
IlRazz...@netscape.net
ICQ   : 67552596
Yhaoo : Razziatore82
-----------------------------------------------
Founder of MediaPlayer Project
http://razziatore.no-ip.com/mpp/

 puoi fare tutto quello che vuoi, con il Java no...
In effetti credo che nella programmazione elettronica capiti spesso di dover 
accedere direttamente alla memoria, usando puntatori, cosa che in Java non č 
possibile (a meno che non si usi Java nativo mi pare) 

 Mi pare siano il C e l'assembly ma per caso c'e' modo di usare anche Java o Python per tali scopi? 
Sono il C e Assembler, anche perchè la struttura di questi µC è molto semplice,
mentre per usare dei linguaggi a livello più alto hai bisogno di un vero e
proprio sistema operativo.
Ci sono schede basate su ARM9 che supportano un sistema operativo Linux e che
potrebbero lavorare con aggetti creati da Java o Python, ma credo che le risorse
in termini di ram e di cicli macchina non sarebbero sufficienti per farli girare
in maniera soddisfacente.
Considera che anche un sistema efficente come QT e C++ ha i suoi problemi in
architetture minimali.
Per cui se vuoi usare i µC tipo AVR o pic devi andare di assembler fino a che ti
è possibile, poi dovrai per forza usare gli scarabocchi di Kernighan e socio,
non c'è altra strada purtroppo.
--
ciao
  Stefano

 non c'è altra strada purtroppo.
Eheh, ritieni il C di Ritchie e socio uno scarabacchio, o la sua versione 
per PIC) :-) 

per PIC) :-) 
La prima che hai detto, non mi piace il C per la sua sintassi orribile, mentre
apprezzo la sua potenza.
--
ciao
  Stefano

 apprezzo la sua potenza.
Però dici di usare assembly finché possibile... il quale ha una sintassi 
improponibile :-) 

 improponibile :-)
Lascialo stare, porello, è un mago, ma è un po' fissato... ;-)

 per caso c'e' modo di usare anche Java o Python per tali scopi?
Nah, i processori che avrebbero dovuto far girara Java nativamente sono
rimasti nei sogni di Sun ed accoliti.
Python è assolutamente improponibile, perché non solo è interpretato, e
quindi ha tempi di risposta assolutamente imprevedibili oltreché lunghi,
poi non è tipizzato, problema ancor peggiore del non poter usare puntatori
(se fosse solo lì il problema, basterebbe definire, a livello di
configurazione del compilatore, variabili allocate staticamente agli
indirizzi corrispondenti ai vari I/O).

improponibile :-) 
Non parlavo dei pic che effettivamente hanno istruzioni e model memory
difficili, salti paginati, stack hardware.
Io uso gli AVR in assembler, ed è tutta un'altra cosa, fidati.
--
ciao
  Stefano

Lascialo stare, porello, è un mago, ma è un po' fissato... ;-)
Vero, ognuno ha le sue fisse.
La mia è  "C is ugly"
--
ciao
  Stefano

 La mia è  "C is ugly"
Per me, in un linguaggio di programmazione, ortogonalità e semplicità
sintattica sono sinonimi. L'assembler, anche uno bello come quello degli
AVR, non può essere ortogonale quanto il C. E non esiste linguaggio più
semplice del C. Senza contare che il C è (quasi) uno solo, asembler ce ne
sono tanti quanti i processori (a parte qualche figata fatta da DEC).

 sintattica sono sinonimi.
Ortogonalità in che senso?
Rispetto a cosa? 

 Ortogonalità in che senso?
Composizione di concetti. Per fare un esempio, se hai matrici e strutture,
devi poter avere anche matrici di strutture.

 sintattica sono sinonimi
di bellezza.

sono tanti quanti i processori (a parte qualche figata fatta da DEC).
Sono a conoscenza delle virtù del C e degli svantaggi degli assembler, ma
proprio non riesco a farmelo piacere, l'autoipnosi non ce la fa.
Quando vedo le graffe, gli * & ; ecc, mi prende un senso di nausea.
Non sto scherzando, è proprio così, e dura da molti anni.  :-(
--
ciao
  Stefano

 improponibile :-) 
Ma povero PIC-assembly, che vi ha fatto di tanto male?? A me non sembra
così male in fondo, sì, forse un po' arzigogolato ma una volta presa
confidenza non è così ostico, naturalmente IMHO!
Ciao!
-- 
Stefano Martini (Italy)
WEB: 
http://www.lemming.it

 ma una volta presa confidenza non č cosě ostico
Ci ho lavorato 10 anni, dici che basta come tempo per prenderci confidenza?
E' vero che perlopiů usavo le macro della Parallax (ho conosciuto Chip
Lance quando lavoravo  negli USA), ma da quando sono passato agli AVR sono
un uomo felice.

 AVRRRR...:-))))
Scusa, quanti anni hai lavorato con gli AVR? E con i PIC?

 Non sto scherzando, č proprio cosě, e dura da molti anni.  :-(
nel tuo linguagio di programmazione cose c'č
al posto di * e &.
Ciao 

 devi poter avere anche matrici di strutture.
Ah, capisco. Ovviamente in assembly tutto ciň non esiste. Credo che valga la 
pena utilizzarlo solo se le prestazione migliorano sensibilmente rispetto al 
C. 

 al posto di * e &.
I punti interrogativi e le "a"? ;-)

 Python č assolutamente improponibile
Se fai caso, gli estimatori di Python spesso rientrano in due categorie: i
perversi (ai quali non bastava il minimalismo criptico del C e volevano
qualcosa di ancor piů feticistico e arcano) e i sysadmin unix (che amano il
Python perché č perfetto per manipolare i loro amati file di configurazione
testuali). :)
-- 
emboliaschizoide.splinder.com

 testuali). :)
Non essendo un sysadmin rientro quindi nei perversi?
No, scherzi a parte, c'ho scritto solo due programmi.
Mi sono divertito molto, ma nello stesso modo in cui ti diverte un
cruciverba del fu Bartezzaghi, ti spremi le meningi per ore ed alla fine
non hai creato nulla di utile.
Cioè, i miei programmi servivano, ma giusto per elaborare, come accennavi,
il log degli accessi ad un sito web Apache. Se avessi saputo come accedervi
con Lex o C, avrei sparambiato parecchio tempo.

 un uomo felice.
Sto dando una occhiata anch'io agli AVR (come ti dicevo nell'altro post)
ed in effetti ammetto che l'asm č un po piů lineare, forse perň non hai
considerato che i linguaggi di programmazione vanno anche a "gusto
personale".


 per caso c'e' modo di usare anche Java o Python per tali scopi?
Nei sistemi embedded per controllo industriale si usano largamente
tool di generazione automatica del codice, come Matlab/TargetLink. Il
codice generato è comunque sempre (ANSI) C, a conferma della potenza
di quel linguaggio, non solo per scrivere "programmi", ma anche come
output intermedio di altri "programmi" ..
saluti,
simone.bern

 anche a "gusto personale". 
Certo che non l'ho considerato. Altrimenti cose ne parlerei a fare?

 personale".
C'è anche un altro parametro da valutare...
Ambedue sono ad architettura RISC (Reduced Instuction Set Computer) 
il che indica un set ridotto di istruzioni.
i PIC però sono per davvero *reduced* (hanno una media di una 40ina 
di istruzioni), gli AVR oltre 120...
-- 
Computers are a more fun way to do the same work you'd have to do without them.
News 2002 [v 2.3] / StopDialer / PopDuster - 
http://www.socket2000.com
Akapulce portal: 
http://www.akapulce.net

 C.
Oppure quando vuoi che il tempo di esecuzione non cambi qualunque dei due
rami di un IF venga eseguito.
Ma anche in questi casi preferisco scrivere in C e copincollare il listato
intermedio (quello che contiene sia il C che l'assembler) del segmento di
codice da ottimizzare nel sorgente. Poi ottimizzo l'assembler lasciando,
quando possibile, il C come commento.
Sě, come commento, dato che la meravigliosa chiarezza del C ti permette di
vedere "a colpo d'occhio" cosa fanno gli statement in assembler (questa era
per SB :p  ).

 con Lex 
Pardon, AWK. Gli anni passano...

 (questa era per SB :p  ).
Avrei regito a questa tua affermazione assurda anche senza la precisazione
sottostante     ;-)
--
ciao
  Stefano

 meravigliosa chiarezza?    BLEAH!
Beh, non č python, ma meglio sicuramente dell'assembly :-) 

Beh, non č python, ma meglio sicuramente dell'assembly :-) 
Dipende da come lo usi.
Io in assembler uso molte macro per le varie funzioni e spesso non ho nemmeno
bisogno di commentare perchč cerco piuttosto di mettere il nome delle variabili,
delle costanti e delle macro in modo che siano autoesplicative.
Anzi, ma io sono della vecchia scuola, scrivo un commento all'inizio della
routine di 3 o 4 righe per spiegare il tipo di ragionamento che sta alla base,
poi metto poco altro.
Anche perchč quello che ti serve ricordare se metti mano ad un programma dopo
mesi o anni č proprio il ragionamento che ha prodotto quella routine, e se lo
devi ricavare dalla istruzioni non č detto che sia immediato.
--
ciao
  Stefano

 Beh, non č python, ma meglio sicuramente dell'assembly :-)
Non sai cos'hai detto! :D

 Ah, capisco. Ovviamente in assembly tutto ciò non esiste.
Sì e no. A quel livello l'ortogonalità sta negli indirizzamenti. Alcuni
CISC permettono di fare, ad esempio, l'AND di due registri, di un registro
ed una locazione di memoria indirizzata direttamente (l'indirizzo è una
costante), indirettamente (l'indirizzo è in un[a coppia di] registro), col
salto doppio (l'indirizzo è contenuto in una locazione di memoria  puntata
da un registro), con offset costante o contenuto in un registro eccetera.
Inoltre c'è da dire che SB certo non usa l'assembler, ma un
macro-assembler. In pratica si è definito un suo linguaggio, che immagino
sia altrettanto ortogonale e semplice (ma certo non conciso) come il C.

 Sì e no. A quel livello l'ortogonalità sta negli indirizzamenti.
Nelle macchine RISC, che non sono caratterizzate dal numero di istruzioni
disponibili, come qualche ignorante potrebbe immaginare e semmai
tromboneggiare come verità, ma da un'architettura load/store, ovvero in cui
i dati vengano copiati dalla memoria ai registri, elaborati ed il risultato
scritto in memoria, si è persa anche questa ortogonalità.
Motivo di più per passare al C. ;-)

 Non sai cos'hai detto! :D
Il punto è che la chiarezza di un linguaggio come python la si vede 
soprattutto in grossi software che girano solo su pc.
Nell'ambito dell'elettronica, è più utile avere la possibilità di lavorare 
con registri e locazioni di memoria, piuttosto che, per esempio, poter 
dichiarare strutture dati molto complesse in una riga. 

 poter dichiarare strutture dati molto complesse in una riga.
E ciò ti pare contribuisca alla charezza?
A dire il vero a me i linguaggi che non sono strongly typed mi stanno
antipatici, perché poco sicuri ed efficienti. Molto bella è però l'idea
dell'"indentazione significativa", che mi piacerebbe veder importata in C.
Anche perché non ne posso più di Alt-123 e Alt-125...

 Direi, più appropriarttamente
Devo smettere di scrivere parole così lunghe da perdermici dentro...
Comunque il mio commento "Non sai cos'hai scritto" era scherzoso e riferito
agli strali che avrebbe lanciato SB. :-)

 E ciň ti pare contribuisca alla charezza?
Prova a scrivere in C una lista in grado di contenere vari tipi di dati ad 
esempio.
Devi fare tutto a mano, non esistendo tali strutture dati.
in Python mi pare fosse sufficiente scrivere:
L = []
e aggiungere qualunque cosa al suo interno. 

 e aggiungere qualunque cosa al suo interno.
Un po' come la mia scrivania, insomma...

 Perchè poi tu non hai fisse?
A parte contro oggetti e polimorfismo?
Beh, mi piace sapere da dove derivano le parole.
Quel filmato ( 
http://www.avrtv.com/2007/09/09/avrtv-special-005/
 ) m'ha
messo una pulce nell'orecchio che non riesco più a togliermi. E dire che
son campato contento per anni senza chiedermi cosa volesse dire AVR.
Sono arrivato a pensare che la V fosse un or inclusivo booleano, ma
probabilmente, AVR sta per Alf-Egil, Vegard, mentre R era il terzo del
gruppo, finito chissà dove.

 Hai mai sentito parlare di union o (rabbrividisco) di void pointer?
Si, ma chiaramente non sono intuitivi come le liste in python. 

 poi non è tipizzato, problema ancor peggiore del non poter usare puntatori
Mi permetto di dissentire parzialmante. Sto studiando python da un po' 
di tempo e ritengo che lo si debba considerare (al pari di java) un 
linguaggio a maggior livello di astrazione rispetto al C (o pascal ecc).
Come java e' bytecode-compilato ed eseguito (interpretato) in una 
virtual machine, questo vuol dire da una parte maggiore portabilita' 
(multipiattaforma), ma dall'altra tempi di esecuzione molto piu' lunghi 
(a spanne mi sembra che un programma python giri su un pentium 3GHz piu' 
o meno veloce come un compilato C o pascal su un pentium a qualche cento 
MHz).
Il fatto di essere a maggior livello di astrazione lo "allontana" 
dall'hardware, non si pensa piu' ai puntatori, ai registri del PC, o 
alle allocazioni/deallocazioni di memoria, e si lavora invece piu' 
comodamente con gli oggetti software (dati, strutture, files ecc).
Non e' vero che non e' tipizzato, ogni oggetto e' di un tipo ben preciso 
ed esistono le conversioni tra i vari tipi, ma non e' obbligatorio 
dichiararli in anticipo. Ogni funzione puo' accettare e restituire 
qualsiasi tipo di oggetto (numeri, liste, altre funzioni) e sta al 
programmatore utilizzare questi oggetti in modo appropriato al contesto 
(di fatto vengono passati sempre i puntatori agli oggetti, ma senza 
bisogno di considerarli o dichiararli esplicitamente puntatori).
Io arrivo dal delphi/pascal, che, come il C, ha una forte tipizzazione 
statica e all'inizio sono rimasto un po' perplesso, ma poi ho visto la 
comodita' di python appena ho provato a riscriverci un assemblatore Z80 
che avevo scritto in pascal anni fa. Finalmente la liberta' dal doversi 
costruire liste e puntatori tra gli elementi delle liste, dal doversi 
preoccupare dell'occupazione della memoria e tutte queste amenita'. Con 
le strutture python, gli iteratori automatici e le molte funzionalita' 
built-in, di fatto il programma l'ho riscritto a tempo record rispetto 
alla fatica che avevo fatto in pascal (e sarebbe stata la stessa cosa in C).
Invece provare a riscrivere unicamente in python un programma di 
controllo hardware attraverso la porta parallela (che in delphi era 
velocissimo e molto corto) sarebbe un'impresa. Per avere risultati 
accettabili bisognerebbe scriversi una DLL esterna in un linguaggio 
"convenzionale".
E quindi, per tornare alla richiesta dell' op, confermo che anche io che 
per i motivi detti sopra per un sistema embedded non lo prenderei 
neppure in considerazione, a meno di compiti veramente banali, o di 
supervisione ad alto livello e non determinanti per le temporizzazioni...
ciao
Claudio_F

 Non essendo un sysadmin rientro quindi nei perversi?
Beh, fra i due è il male minore. ;-)
-- 
emboliaschizoide.splinder.com

 Anche perché non ne posso più di Alt-123 e Alt-125...
Se me lo dicevi prima per Natale ti regalavo una tastiera con le 
graffe.... ;)
Marco

Marco Trapanese ha scritto:

Tutte le tastiere hanno le graffe anche quelle italiane, è un po' come 
il simbolo dell'euro ( € ) che si ottiene premendo il tasto Alt Gr + e, 
nello stesso modo per ottenere la graffa basta premere Alt Gr + é ( dove 
è e' ottenuto a sua volta dalla pressione di è + il tasto shift ) in 
pratica basta premre Alt Gr + shift + è... io oramai lo trovo "automatico"
-- 
Il Razziatore,
"Lo sviluppo di una nazione si misura anche dallo stato della sua rete 
ferroviaria". Camillo Benso Conte di Cavour
"Per tutto quanto non previsto nel presente regolamento il capostazione 
deve usare senno e ponderatezza." Regolamento d'esercizio FS
-----------------------------------------------
MSN   : 
IlRazz...@netscape.net
ICQ   : 67552596
Yhaoo : Razziatore82
-----------------------------------------------
Founder of MediaPlayer Project
http://razziatore.no-ip.com/mpp/

 Tutte le tastiere hanno le graffe anche quelle italiane
ehm... era una battuta :)
Non capivo come mai Bertolazzi continui a usare Alt + 123/125...
Ciao!
Marco

 scritto in memoria, si è persa anche questa ortogonalità.
Ma lol... Bertolà, dammi retta... Abbassa la cresta.
i RISC non sono solo caratterizzati dal *NUMERO* di istruzioni 
(tant'è appunto che tra PIC e AVR c'è un divario enorme pur essendo 
ambedue RISC) ma neppure solo dall'architettura load/store. E' un po'
più complessa la faccenda, è l'insieme di alcune caratteristiche che 
permette la definizione di RISC. Anche i CISC copiano i dati dalla 
memoria ai registri interni per poi riportarli in memoria se è per 
questo... Non è una prerogativa RISC. La differenza è che il CISC lo 
fa da solo senza che il programmatore lo sappia, utilizzando una 
singola istruzione (Complex Istruction Set Computer). Il problema è 
però che questa *singola* istruzione il più delle volte comporta 
diversi cicli di clock al contrario dell'architettura RISC nella 
quale il 99% delle istruzioni è risolta in un singolo ciclo. Il set 
ridotto di istruzioni, poi, non è aleatorio come pensi e non è 
neppure da sottovalutare la grandezza del set di istruzioni. 
RIcordarsi 35 istruzioni bae non è la stessa cosa di ricordarne 120.
-- 
Resistance is useless!  (If < 1 ohm)


Quando vedo le graffe, gli * & ; ecc, mi prende un senso di nausea.
E' anche questione di gusti, io trovo graffe, asterischi, & e compagnia
cantante molto... artistici !!!

 Si, ma chiaramente non sono intuitivi come le liste in python.
Boh, se lo dici tu...

Marco Trapanese:

Lo so. Era evidente.

 Beh, fra i due č il male minore. ;-)
ROTFL!

 supervisione ad alto livello e non determinanti per le temporizzazioni...
Siamo quindi d'accordo. Quello che ho scritto sopra non lo cancello solo
perchč mi fa fatica. ;-)

 più complessa la faccenda
Vedo con piacere che inizi ad imparare qualcosa.
Continua così. Se ti impegni, tra 20 anni potremo riparlarne. Forse.

 Maggiura! Altro esempio? Il crivello di Eratostene. Altro esempio?
Può sempre capitare di usarla, il codice elegante spesso semplifica la 
lettura del codice, anche se a volte è difficile crearlo. 

sia altrettanto ortogonale e semplice (ma certo non conciso) come il C.
Certo, è così.
In effetti io uso una serie di macro che mi permettono di usare il µC in modo
ottimale.
Avevo fatto degli esempi quest'estate, dove dicevo che la gestione delle
stringhe era fatta sulla base di istruzioni basic e facevo qualche esempio, qui
c'è tutto il thread:
 
http://tinyurl.com/8ncjld
--
ciao
  Stefano

 il codice elegante spesso semplifica la lettura del codice
Come soglio dire "l'importante è che il programma sia bello, se non
funziona non importa, si troverà senz'altro il modo di farlo funzionare".
Però la ricorsione non credo sia l'esempio migliore da citare come esempio
di codice elegante E facile da leggere.

gruppo, finito chissà dove.
Forse, ma non sapere ancora cosa vuol dire 'ei vii ar' incrementa il fascino di
questi oggettini.
--
ciao
  Stefano

 RIcordarsi 35 istruzioni bae non č la stessa cosa di ricordarne 120.
Con la differenza che i PIC ne possono avere da 35 a 70, e quindi ti devi
ricordare quali istruzioni supporta la CPU che stai usando, mentre gli AVR,
a parte l'istruzione di moltiplicazione e quelle per autoprogrammare la
flash (ma i chip attuali credo la supportino tutti) hanno sempre le stesse
istruzioni.
 

 questi oggettini.
Perchč, secondo te non l'hanno fatto apposta a chiudere cosě il filmato?
;-)

;-)
Credevo che non gli avessero detto che il telefonino va spento durante le
interviste, e poi la telecamera era proprio schermata male    :-)
--
ciao
  Stefano

 Vedo con piacere che inizi ad imparare qualcosa.
LOL. Abbassa la cresta, come ti ripeto... Ribadisco il mio pensiero: 
tu non capisci i concetti ovvio poi che escano strafalcioni ridicoli.
-- 
You're only young once. You're immature forever. 


 istruzioni.
Le istruzioni aggiuntive riguardano i moduli propri di ogni PIC (ADC,
Comparatore, CAN-BUS, EEPROM...) la base rimane sempre quella di 
33..35 istruzioni. 
-- 
From C:\*.* to shining C:\*.*


 Nella tua crestina...
Alla faccia della malafede!

 Alla faccia della malafede!
Sono dirimenti tra DUE RISC, asino! Non per stabilire se un 
processore è risc o no!!!
-- 
Help!  I'm trapped in a Chinese computer factory!


I pic impiegano 4 cicli ma per TUTTE le sue istruzioni. 
Non č proprio cosě, alcune hanno piů cilcli, come del resto avviene negli AVR
che possono impiegare fino a 4 cicli per ICALL e 5 per CALL e IRET.
Per esempio BTFSS, CPFSEQ e diverse altre vengono eseguite in 1,2 o 3
cyc (da 4 clk)
http://ww1.microchip.com/downloads/en/DeviceDoc/31029a.pdf
--
ciao
  Stefano

 Comparatore, CAN-BUS, EEPROM...)
Bella zozzeria!


"...al contrario dell'architettura RISC nella quale il 99% delle 
istruzioni č risolta in un singolo ciclo.."
-- 
Every program is a part of some other program, and rarely fits.


 di istruzioni), gli AVR oltre 120...
Alla faccia della malafede...
Mi pare di aver già fatto una ben magra figura ad abbassarmi al tuo
livello. Tornatene nel kill-file e restaci.

 istruzioni č risolta in un singolo ciclo.."
L'1% di 33 mi risulta essere 0,33, che č minore sia di 1 che di 2 che di 3

 Bella zozzeria!
Vedi tu se è intelligente includere istruzioni per l'adc, ad esempio,
in un microcontroller che non lo possiede.
-- 
What's another word for Thesauras? 


 livello. Tornatene nel kill-file e restaci.
Bravo, torna a giochicchiare con il killfile (solo i deboli di mente 
ne hanno bisogno, il vero killfile è nel cervello di chi legge) tanto
le ca%%ate continuerai a sparararle ed io te le farò notare lo 
stesso.
-- 
No line available at 300 baud.


 L'1% di 33 mi risulta essere 0,33, che è minore sia di 1 che di 2 che di 3
Fai VERAMENTE fatica ad afferrare i concetti eh?
-- 
Lisp Users: Due to the holiday, there will be no garbage collection on Monday.


 di codice elegante E facile da leggere.
Diciamo che dipende da caso a caso :-) 

 singola istruzione spesso involve un numero molto più elevato di 
Mi hai contestato le cose più inutili e non questo strafalcione...
TCk*4 (Sarebbe stato Fck/4  non Ck/4 come ho indicato 
erroneamente)...
-- 
Mommy!  The cursor's winking at me!


 Ho scritto questo?
Beh, si, per averlo scritto lo hai scritto. Diciamo che e' 
un'affermazione incompleta, sto pensando all'autore del post che magari 
non conoscendo questo linguaggio trae conclusioni errate.
Quella di babbo natale non l'ho capita, ma fa lo stesso.
ciao
Claudio_F

 Quella di babbo natale non l'ho capita, ma fa lo stesso. 
La portabilità dei linguaggi interpretati è solo marginalmente migliore di 
quella dei compilati. Quando si ha a che fare con OS diversi, in 
particolare se hanno GUI diverse, è sempre un macello.

 bislacchi.
anche da questo punto di vista i due animaletti si somigliano parecchio,
solo che i mnemonici del PIC sono una scelta un disgraziata.
saluti e auguri

 solo che i mnemonici del PIC sono una scelta un disgraziata.
E ti pare poca cosa? ;-)

 COMPLEX INSTRUCTION!
E' l'"instruction set" ad essere "complex", non le singole istruzioni,
bestia!

 bestia!
Io mi chiedo (anzi adesso capisco il perchè delle tue ca%%ate 
galattiche) come tu possa capire l'elettronica senza riuscire a 
comprendere l'inglese (ma nemmeno l'italiano)...
http://en.wikipedia.org/wiki/Complex_instruction_set_computer
"...is a microprocessor instruction set architecture (ISA) in which 
each instruction can execute several low-level operations, such as a 
load from memory, an arithmetic operation, and a memory store, all in
a single instruction...."
http://it.encarta.msn.com/encyclopedia_761563266/CISC.html
"...processore che impiega un set di istruzioni complesse a livello 
di linguaggio assembly. L'elevato grado di complessità delle 
istruzioni permette modalità di calcolo complesse e flessibili, ma 
impone un numero di cicli di clock elevato..."
http://www.bookrags.com/research/cisc-complex-instruction-set-comput-w
cs/
"...A Complex Instruction Set Computer (CISC) supplies a large number
of complex instructions at the assembly language level..."
Ultimo ma non ultimo un *escursus* sul Tanenbaum...
http://vip.cs.utsa.edu/classes/cs2734s97/lecture41.html
Torna a mungere và...
-- 
"Mommy, what does 'FORMATTING DRIVE D:' mean"? 


 E ti pare poca cosa? ;-)
(oops  era " un po' disgraziata")
non e' poca cosa, ma nemmeno decisiva; insomma, li puoi anche odiare a
morte, ma qualche volta la scelta migliore e' un PIC, non puoi farci
niente.
saluti e auguri

 particolare se hanno GUI diverse, è sempre un macello.
Beh, certo, di totalmente portabile c'e' solo il nucleo del/dei 
linguaggi, tutti gli accessi esterni hanno delle differenze. 
Personalmente cerco di mantenermi il piu' possibile al minimo comune 
denominatore tra le diverse implementazioni.
ciao
Claudio_F

 saluti e auguri
Auguri e sentiti ringraziamenti anche a te.

 fare un'idea piuttosto precisa.
Si, tempo fa ho studiato qualcosa su Python.
In ogni caso volevo solo precisare che anche Python è tipizzato in quanto il 
tipo è ben definito proprio dal valore che si assegna alla varaibile, solo 
che è a tipizzazione dinamica, mentre il C è a tipizzazione statica.
Auguri 

 linguaggi, tutti gli accessi esterni hanno delle differenze. 
Esattamente. Il C, se vogliamo, è il meno portabile dei linguaggi
portabili, dato che nemmeno i tipi semplici sono univocamente definiti.
Di sicuro c'è solo che sizeof(char) <= sizeof(short) <= sizeof(int) <=
sizeof(long).
Il bello del C è appunto il fatto di essere un linguaggio assolutamente di
basso livello, un "assembler strutturato" che ne conserva buona parte delle
caratteristiche migliori, aggiungendovi però una buona parte delle
caratteristiche tipiche dei linguaggi ad alto livello.

 caratteristiche tipiche dei linguaggi ad alto livello.
Questo e' un punto di vista interessante, il C l'ho appena sfiorato 20 
anni fa su una macchina unix, ma per qualche motivo non l'ho mai 
approfondito, preferendo l'assembler per il bassissimo livello e altro 
(basic prima, pascal/delphi poi) per l'alto livello.
ciao
Claudio_F

 
o forse hai _saputo_ farlo iterativamente...oppure avendola usata una volta 
in 30 anni ne sei ugualmente un grande esperto?
-- 
N1 under...
zx-6r '04 Cocci & Dolori
CRe 250 '99 Almost Glue
XS 400 "90" Nescafè Racer

 in 30 anni ne sei ugualmente un grande esperto?
Può darsi. Mi fai un po' di esempi in cui TU l'hai usata?

 sottototali strani, ho dovuto farlo iterativamente.
Ah, no, ora ricordo, era il Visual Basic che andava in stack overflow, non
ricordo se immediatamente in quanto non capace di generare codice
rientrante oppure perché l'albero esplorato era troppo grande.
Sono sempre in attesa di esempi di ricorsione diversi dalla navigazione di
alberi (cosa abbastanza rara da implementare, nella vita reale) e dal
crivello di Eratostene.
Suggerimento: qualche applicazione di "intelligenza artificiale".
In particolare, viste le insinuazioni di N1, mi piacerebbe sentirne
qualcuna da lui.

 Suggerimento: qualche applicazione di "intelligenza artificiale".
Casi che mi sono capitati:
- Calcoli con parentesi (che pero' si risolvono ugualmente e piu' 
intuitivamente anche con la notazione RPN).
- Scansione del file system (albero)
- Inclusione a N livelli di testi all'interno di un testo (albero anche 
questo, ma con una lista dinamica di istanze "lettrici di file" si fa 
anche senza ricorsione)
- Motore inferenziale prolog (albero di fatti e regole)
e quelle funzioni matematiche intrinsecamente ricorsive nella loro 
definizione (come il fattoriale)

 definizione (come il fattoriale)
Una cosa utilissima, insomma, senza la quale l'informatica non esisterebbe.
 Un po' come le liste polimorfe. ;-)

  Un po' come le liste polimorfe. ;-)
Una "lista polimorfa" era un concetto che prima del python neanche mi 
sfiorava. Intendiamoci, non sto elogiando il python in cui trovo ancora 
molte cose "scivolose", ma solo dicendo che e' una possibilita' in piu' 
sull'astrazione nell'uso dei dati... tornando al prolog o a un qualsiasi 
expert-system, algoritmo IA, poter pensare a liste di dati e oggetti 
arbitrari o arbitrariamente associabili/processabili (intesi anche come 
un ulteriore linguaggio di ordine superiore da elaborare) forse potrebbe 
diventare interessante.
Anzi, forse sarebbe stato il sogno di Turing, che, con il fermento di 
idee che aveva, a quel tempo doveva accontentarsi delle memorie 
ultrasoniche e di riuscire a comandare una telescrivente ;)

 Turing
:'(