-- DeboraGiulivo - 18 Apr 2002

A cura di Debora Giulivo e Sara Moggi

CLASSIFICAZIONE DELLE ARCHITETTURE

In riferimento al modo in cui la CPU manipola gli oggetti nell’elaborazione è possibile individuare quattro principali classi:

  • Modello a stack (pila)
  • Modello memoria-memoria
  • Modello registri-memoria
  • Modello registri-registri

Il modello a stack tipico degli anni ’60-‘70 (modelli BURROGH B550 e HEWLETT PACKHARD 3000) si diffuse grazie all’uso di operazioni implicite (es. istruzione ADD) svantaggio: eccessivo uso della pila.

Con il modello memoria-memoria tutte le operazioni avvengono tra operandi in memoria e i risultati vengono posti in essa. Con un’operazione vengono specificate le locazioni di memoria dei due operandi e del risultato. svantaggio: l’accesso in memoria richiede più tempo rispetto all’accesso ai registri in quanto tutte le operazioni sono sincronizzate.

Un altro modello denominato registri-memoria (es. ACCUMULATORE) tipicamente le operazioni avvengono tra il contenuto di un registro e quello di una cella di memoria con il risultato di un codice abbastanza compatto. svantaggio: il codice stesso è poco flessibile, si perde infatti “libertà di movimento”.

Infine il modello registri-registri con cui si hanno “tanti”( al massimo 32) registri ad uso generale, equivalenti tra loro. Per ottenere dei vantaggi con questo modello si mantengono gli operandi nei registri per tutto il tempo che serve , altrimenti si effettuerebbe un’operazione in più rispetto al modello precedente.

ORDINAMENTO ED ALLINEAMENTO

  • Ordinamento:
Se si considera una parola composta da 4 bytes, il suo indirizzo verrà specificato rispetto al primo byte. Diversamente accade nel modello CDC 6600. Infatti, le parole sono composte da 60 bit divisi in 10 gruppi da 6 bit, e il loro indirizzo non fa riferimento al byte. Questa struttura risulta problematica se si vuole accedere a più sottogruppi di bit o a un singolo bit. Ciò viene effettuato tramite una procedura detta mascheramento che permette di isolare le informazioni che interessano.

es:

%DRAWING{tabella1}%

ogni quadratino rappresenta un gruppo da 6 bit. Se voglio far riferimento ai due gruppi evidenziati, creerò una maschera così definita:

%DRAWING{tabella2}%

Si possono distinguere due organizzazioni principali a byte:

  • Little Endian (Architetture INTEL)
  • Big Endian ( Architetture MOTOROLA 680x0)

Little Endian

%DRAWING{tabella3}%

Il byte che dà l’indirizzo della parola è il meno significativo di quest’ultima.

Big Endian

%DRAWING{tabella4}%

Il byte che dà l’indirizzo della parola è il più significativo di quest’ultima.

Esistono poi architetture di tipo BI-ENDIAN (es Power PC)le quali, a seconda del valore di un particolare bit, diventano Big Endian o Little Endian.

Non si può stabilire quale sia il modo migliore di ordinamento.

Allineamento: Non sempre le parole sono formate da due bytes

Es1:

%DRAWING{tabella5}%

se voglio memorizzare 1 byte, 1 half word e 1 byte senza sprecare memoria otterrò:

%DRAWING{tabella6}%

1 byte 1 half-word 1 byte

In questo modo però si perde l’allineamento e quindi è possibile accedere alle varie parti se esistono delle direttive specifiche. In Spim troviamo la direttiva .align che stabilisce ad esempio la modalità di indirizzamento.

Es2: un altro esempio di parola non allineata. La parola è posizionata in due locazioni di memoria non consecutive.

%DRAWING{tabella9}%

In questo caso l’allineamento prevede una rete opportuna che permette di trasferire parole non allineate.

DIFFERENZE SECONDO L’ALLINEAMENTO NELLE ARCHITETTURE RISC E CISC

Nelle RISC troviamo le parole allineate Nelle CISC è possibile trovare istruzioni non allineate anche se si cerca di evitarlo

IL LINGUAGGIO ASSEMBLER

Istruzioni ---> stringhe binarie

In linguaggio assembler Istruzioni ---> codifica-mnemonica delle istruzioni macchina

Il linguaggio assembler (più propriamente detto Assembly) è un linguaggio a basso livello, che rispecchia quindi l’architettura della macchina. Anche se i linguaggi assembler tra di loro hanno delle caratteristiche comuni, sono fortemente legati alla macchina per cui sono stati progettati. L’_ASSEMBLATORE_ (o Assembler) traduce le istruzioni in linguaggio assembler in istruzioni in linguaggio macchina ed è proprio questo programma che gestisce codici operativi, registri ed etichette permettondo di usare una simbologia più chiara e più semplice. I programmi possono esserre divisi in moduli tradotti e scritti separatamente.

Ogni modulo sorgente o segmento di programma scritto in assembler è passato all’assemblatore che lo traduce in modulo oggetto (codice oggetto istruzioni macchina + informazioni aggiuntive) non ancora eseguibile. Come citato prima l’assemblatore divide il programma in vari moduli ma non è in grado di crearne un unico eseguibile. Si usa per questo scopo un altro programma (LINKER) che tiene conto delle librerie di funzioni messe in gioco dai moduli oggetto e crea un unico modulo eseguibile.

Riassumendo:

COMPITI DELL'ASSEMBLATORE

  • leggere il modulo sorgente
  • tradurre istruzioni da linguaggio assembler a linguaggio macchina
  • aggiungere informazioni che servono a collegare diversi moduli oggetto e funzioni di libreria

COMPITI DEL LINKER

  • ricerca funzioni libreria citate
  • determina indirizzi di memoria da ciascun modulo che il codice macchina dovrà occupare e le trasla ( o riloca) in indirizzi assoluti
  • risolve i riferimenti ad altri moduli
Nel caso di programmi ad alto livello si può passare attraverso un altro modulo detto COMPILATORE il quale da’ origine a due uscite distinte: programma in linguaggio assembler oppure programma oggetto

I programmi assembler possono derivare o dal compilatore o dalla programmazione umana. Il compilatore effettua un lavoro diverso dall’assemblatore:

  • esegue automaticamente le istruzioni
  • trasferisce sequenzialmente in memoria i dati
Il programmatore a differenza del compilatore
  • mantiene una visione globale dell’organizzazione della macchina
  • ha la possibilità di lavorare su una specifica architettura
  • ha una comprensione migliore degli algoritmi
Non si può stabilire se sia più conveniente programmare direttamente in linguaggio assembler o se programmare ad alto livello e poi compilare. Si può invece prediligere l’uno rispetto l’altro in base alle esigenze.

PIC (Position Independent Code) Permette la rilocazione facilitata: evita modalità di indirizzamento assoluto à indiruizzamento interno alla sessione Grazie ad esso riesco a posizionarmi in qualunque posto Rif. assoluto à Salta alla locazione XYZ ( + vincolante) Rif. PIC à Salta di 20 posizioni rispetto all’attuale

Topic attachments
I Attachment History Action SizeSorted ascending Date Who Comment
Unknown file formatdraw tabella7.draw r3 r2 r1 manage 0.1 K 2002-04-18 - 15:18 DeboraGiulivo  
GIFgif tabella7.gif r3 r2 r1 manage 0.1 K 2002-04-18 - 15:18 DeboraGiulivo  
Unknown file formatdraw tabella6.draw r2 r1 manage 0.9 K 2002-04-18 - 14:55 DeboraGiulivo  
GIFgif tabella1.gif r2 r1 manage 1.2 K 2002-04-18 - 14:36 DeboraGiulivo  
Unknown file formatdraw tabella1.draw r2 r1 manage 1.4 K 2002-04-18 - 14:36 DeboraGiulivo  
GIFgif tabella2.gif r1 manage 1.4 K 2002-04-18 - 14:40 DeboraGiulivo  
Unknown file formatdraw tabella5.draw r1 manage 1.5 K 2002-04-18 - 15:39 DeboraGiulivo  
GIFgif tabella5.gif r1 manage 1.6 K 2002-04-18 - 15:39 DeboraGiulivo  
GIFgif tabella6.gif r2 r1 manage 1.6 K 2002-04-18 - 14:55 DeboraGiulivo  
GIFgif tabella3.gif r1 manage 1.7 K 2002-04-18 - 14:44 DeboraGiulivo  
GIFgif tabella4.gif r1 manage 1.7 K 2002-04-18 - 14:48 DeboraGiulivo  
Unknown file formatdraw tabella2.draw r1 manage 2.7 K 2002-04-18 - 14:40 DeboraGiulivo  
GIFgif tabella9.gif r1 manage 2.9 K 2002-04-18 - 15:37 DeboraGiulivo  
Unknown file formatdraw tabella4.draw r1 manage 3.3 K 2002-04-18 - 14:48 DeboraGiulivo  
Unknown file formatdraw tabella3.draw r1 manage 3.4 K 2002-04-18 - 14:44 DeboraGiulivo  
Unknown file formatdraw tabella9.draw r1 manage 4.0 K 2002-04-18 - 15:37 DeboraGiulivo  
Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r2 - 2002-04-18 - DeboraGiulivo






 
Questo sito usa cookies, usandolo ne accettate la presenza. (CookiePolicy)
Torna al Dipartimento di Informatica
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback