- Scritto da: unaDuraLezione
> - Scritto da: tucumcari

> No, lo puoi fare in un linguaggio che ti dia
> accesso diretto non solo ad ogni cella della RAM
> ma anche agli indirizzi speciali che mappano i
> dispositivi hardware (non solo esterni ma anche i
> chip interni
> compresi).

Quindi praticamente con qualunque linguaggio!
CVD.
Quanto ai dispositivi "memory mapped" con IO mappato direttamente sulle aree di memoria è una caratteristica di alcune architetture (segnatamente motorola 68000 ad esempio) niente affatto generalizzata e generalizzabile Intel (solo per fare un esempio tra i tanti) funziona diversamente...
E quindi sempre li stiamo!
Se scrivi puttanate le scrivi:
a) in qualunque linguaggio
b) in assembler vai poco (troppo poco) lontano in termini di generalizzazione di quello che scrivi.

>
> Con *due* istruzioni toglievo l'interrupt al SO e
> lo ridirezionavo alla mia applicazione. Fatto ciò
> potevo passare sopra la RAM utiliizzata dall'OS
> senza far crashare la mia applicazione che
> continunava a girare senza problemi ed ora poteva
> usare tutta la RAM della
> macchina.
Capirai ... disable interrupt!
Mecoj.. di nuovo...
E secondo te quello che ti impedisce (o meglio ti impedirebbe) di "avere a disposizione" tutta la ram della macchina è il sistema o il linguaggio?
(N.B. la risposta la hai implicitamente già data).
E dimmi (sempre secondo te) cosa impedirebbe (una volta tolto dalle balle il sistema appunto) ad un programma scritto in C di avere accesso a tutta la ram?
> Puoi farlo con un linguaggio che utilizza un
> framework?
Il C non utilizza nessun framework casomai serve per scriverlo il framework!

> Puoi farlo con un linguaggio che utilizza
> chiamate di
> sistema?

Il C in se e per se (come linguaggio) non utilizza "il sistema" sono le librerie (sempre scritte in C) che lo utilizzano se glielo chiedi!
Come fai altrimenti a scrivere un OS (che ovviamente non c'è ancora) in C se il C usa il sistema che stai scrivendo?
Te lo sei mai chiesto?
Oppure non sai cosa sia davvero il C?

> Nello scensario che ho descritto, non
> funzionerebbe nemmeno 'hello world', mentre i
> miei programmi andavano lisci come
> l'olio.
Peccato che 'Hello world' di per se non significa altro che appunto sei fuori contesto!
Hai mai provato a scrivere 'hello world' senza sistema e librerie esclusivamente in assembler?
Io si... e so che concettualmente è la stessa cosa (in termini di IO routines ecc.) qui quella che è totalmente fuori contesto è la tua asserzione in merito a "hello world' che (notoriamente) può essere scritto in qualunque linguaggio (appunto) assembler compreso!

>
> > > Potevo parallelizzare perfettamente
> > l'utilizzo
> > > dei chip grafici e del
> > > processore.
>
> > Quelle comunque sono stringhe di bit e il
> chip
> > grafico (che non è il processore) non lo
> > "programmi" nel senso stretto del termine gli
> > mandi una stringa di bit che ha un senso nel
> > "suo" codice macchina che non è certo quello
> del
> > "main
> > processor"!
>
> Primo, hai frainteso: ho scritto parallelizzare
> chip ghrafici *E* processore (main
> CPU).
Parallelizzare i chip grafici?
Quali chip?
Parallelizzare che? l'esecuzione sui chip? o cosa altro?
Mi pare che tu abbia le idee alquanto confuse!
> Secondo, al blitter di Amiga (coprocessore di
> accelerazione grafica) mandavo pochi byte agli
> indirizzi mappati in RAM: erano nient'altro che i
> paramatri e le chiamate alle funzioni del
> blitter. Quindi è come dici
> tu.
Funzioni? chiamate? a cosa?
Ma non avevamo detto che tu facevi a meno dell'OS?
.

> *MA* il Copper (coprocessore video) invece era un
> RISC con 4 tipi di istruzione (ognuna coi suoi
> parametri numerici) col quale potevi fare
> parecchie
> cose.
E quindi ?
Mica erano le stesse istruzioni della CPU!

> Lo *programmavi* esattamente come una CPU
> utilizzando il suo linguaggio ed oltre ad
> elaborare tutto ciò che ha a che fare col raster
> potevi comandare gli altri chip (compreso il
> blitter). Quindi poateva fare le veci della CPU
> per molti
> aspetti.
Certo che un chip lo "programmi come una CPU" è una CPU! (sia pure non general purpose) quello che ho detto io è che ha le SUE istruzioni che non sono affatto le stesse (quindi non è lo stesso assembler) che usi per la CPU propriamente intesa!

>
> > > Fare la stessa cosa in C, ottimizzando
> ogni
> > > chiamata hardware era
> > > impensabile.
> >
> > Davvero? e perchè?
>
> perché una routine Assembly scritta in un'ora era
> meglio performante di un qualsiasi codice
> compilato.

Se è una semplice routine può essere.... ma come ti ho già detto (fin dall'inizio) basta passare il limite delle 1000 righe (facilissimo passarle in un progetto "reale" assembler based) e quello che dici non è già più (dimostrabilmente ripeto) vero!

> Ed ottimizzando all'estremo quella routine
> assembly, diventava due/tre volte più veloce
> della sua prima
> scrittura.
"Ottimizzando" vuole dire solo che avevi scritto male in prima "stesura" se parli di assembler "ottimizzare" in assembler significa "riscrivendo". ne più ne meno!

> Tenendo conto che si avevano 7mhz di processore
> trai tu le
> conclusioni.
Ho usato processori molto ma molto più lenti di un 68000 a 7 mhz! in C!

> *Il risulatato è quello che conta* allora non si
> riusciva a fare roba decente in real time in C,
> oggi si
> può.
è un limite della implementazione del compilatore che avevi su Amiga non del linguaggio in se!
Ma tu sai distinguere tra implementazione e linguaggio in se o no?

> se la pensassero tutti come te avremmo bisogno di
> macchine potenti il doppio per fare le stesse
> cose.
Infatti tutti scrivono in assembler...