Differenza tra programmazione "embedded" e programmazione normale: un chiarimento

[paolino_delta_t]

Concordo con M.A.W. Purtroppo i dirigenti di molte aziende medio/piccole non hanno la più pallida idea di cosa si nasconde dietro il termine embedded. Pertanto lo usano a sproposito.

Giusto per portare un esempio chiarificatore, nel ramo embedded ti potresti ritrovare a lavorare con una cosa del genere http://www.marvell.com/network-proce...-architecture/

Bye bye Von Neumann!!

[M.A.W. 1968]

Giusto per portare un esempio chiarificatore, nel ramo embedded ti potresti ritrovare a lavorare con una cosa del genere http://www.marvell.com/network-proce...-architecture/

Bye bye Von Neumann!!

L'architettura proposta dal geniale Von Neumann, nella quale dati e programmi condividono la medesima memoria fisica, aveva chiaramente senso negli anni Quaranta e Cinquanta dello scorso secolo, quando è stata concepita. Garantiva in particolare la grande economicità e la flessibilità necessarie ai primi tentativi militari di general purpose computing, contro la relativa rigidità del concetto elaborato parallelamente ad Harvard - che richiedeva un preciso dimensionamento iniziale delle quantità di memoria fisica da destinare rispettivamente a dati e programmi.
In realtà, nonostante i limiti realizzativi e tecnologici, anche nel secondo caso era previsto fin dall'inizio un certo grado di modularità e configurabilità, ma non sottilizziamo: si trattava comunque di operazioni fisiche da eseguire sui banchi di memoria, fattibili praticamente solo a macchina spenta, al limite con una sorta di hot swap semiautomatico, ma non certo in modo dinamico e a runtime come nella VN.

Al giorno d'oggi, dopo oltre mezzo secolo, l'architettura VN così pervasivamente implementata nei PC ha mostrato ampiamente tutti i suoi limiti, che è difficile perfino elencare compiutamente senza rischiare omissioni rilevanti: non solo risulta prestazionalmente perdente contro i concetti (geniali) del parallel computing e delle piattaforme embedded, che negli ultimi anni le architetture mainstream tentano malamente di emulare, ma è fonte di una quantità enorme di problemi di robustezza e sicurezza (facile accesso allo stack ed alla memoria riservata in genere, eseguibilità dei dati, self-morphing...) che moderni SO e CPU tentano di arginare con limiti e partizionamenti di tipo logico, ma che su altre architetture sono semplicemente risibili come minacce, perché fisicamente infattibili (e di fatto prive di reali omologhi di pari pericolosità).

Basti solo pensare che su tutte le architetture Harvard, implementate anche nelle economicissime MCU con le quali giocherellano legioni di amatori (PIC, ST, AVR, H8/300, etc...) il caricamento contemporaneo di istruzione (dalla program memory) e dato (dalla RAM dati o file register) consente di raddoppiare senza sforzo le prestazioni rispetto alla classica CPU Von Neumann corrispondente (es. 8086): in talune architetture denominate Super Harvard (tipici ad esempio i DSP SHARC) tali concetti sono poi portati all'estremo, ed è possibile partizionare ulteriormente le memorie creando aggregazioni nelle quali i dati vengono interpretati con larghezza di parola variabile, facendo così coesistere segmenti a 16 o 32 bit con altri a 80 bit, il tutto gestito in hardware senza ricorso a farraginoso microcodice e garantendo l'esecuzione di ogni istruzione in un singolo ciclo di clock. La biodiversità del mondo embedded è semplicemente impressionante anche per chi ci lavora da una vita.