Newsgroup: it.comp.programmare
Titolo: Programma che parte prima dell'OS

Salve,
mi sapreste dire se per sviluppare un programma che parta prima del sistema 
operativo, necessiti l'uso di assembly?
Supponiamo di voler creare una banale finestra con un pulsante. E' possibile 
svilupparla con un ambiente di sviluppo (come C++ builder) e poi fare in 
modo che parta prima del sistema operativo?
Ci sono istruzioni standard che vanno a modificare alcuni settori dell'hard 
disk?
Grazie 

 sistema operativo, necessiti l'uso di assembly?
Il sistema operativo e', essenzialmente, l'interfaccia tra i programmi e
l'hardware (facendo uso dei driver software dei vari dispositivi).
Se vuoi scrivere un programma che parta prima di esso e quindi ne faccia a
meno, ti tocca di gestire direttamente l'hardware direttamente.
La vedo moooooooooooooooooooooooooooooolto dura.
-- 
Stefano L.

 La vedo moooooooooooooooooooooooooooooolto dura.
Mi basta qualcosa di molto semplice per cominciare a capire la logica da 
seguire.
Ad esempio la visualizzazione di un semplice messaggio di testo. 

 Ad esempio la visualizzazione di un semplice messaggio di testo.
Appunto, dove la vuoi visualizzare ?
Sulla console seriale, Quale porta seriale ? Gestita da quale scheda ?
Oppure sul video collegato alla scheda vga ?
Quale scheda VGA, collegata su quale bus ? 
E poi la tastiera e' collegata alla porta PS2 o USB ?
Quale porta USB ? gestita da quale scheda, chip ecc.
Ecc. ecc. ecc. ecc. 
-- 
Stefano L.


vorresti in pratica fare quello che fa normalmente un bootloader
grub e' open source studiatelo e al limite utilizzalo cos� come �
http://www.gnu.org/software/grub/

 Quale porta USB ? gestita da quale scheda, chip ecc.
Serve interfacciarsi alla tastiera anche per la sola visualizzazione? 

 grub e' open source studiatelo e al limite utilizzalo cos� come �
Penso che sia un progetto troppo ampio per iniziare a capire come scrivere 
qualcosa di semplice che parta prima dell'OS 


Forse dovresti spiegare meglio cosa vuoi fare e non solo come vuoi farlo 
(partendo prima dell'OS).
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non � valido)


dovrai sempre lavorare sul MBR e senza riferimenti sicuri � meglio non
metterci mano
in teoria potresti lavorare come il vecchio DOS facendo direttamente le
chiamate al BIOS e poi riagganciarti al bootloader del SO che verrebbe
chiamato successivamente
se mastichi assembly non � difficile in C la vedo un filino pi�
difficile comunque se intercetti gli int del bios e ne ottieni gli
indirizzi fisici potresti usare la call dirette e passare i parametri
operando in real mode non conosco per� la procedura per riagganciare il
SO successivo forse spulciando il codice grub alla voce chainloader
potresti trovare la soluzione

 (partendo prima dell'OS).
Come dicevo, per iniziare mi va bene anche una sciocchezza, tipo un 
messaggio di testo che viene visualizzato per 5 secondi (o magari attende la 
pressione del tasto invio) e poi fa partire il sistema operativo. 

 Grazie

 potresti trovare la soluzione
Effettivamente questa e' la cosa rognosa: e non solo questa.
Anche inserire correttamente il compilato nel MBR per farlo partire non 
e' uno scherzo, con l'aggravante che sputtanando il MBR il rischio di 
fumarsi il disco e' ampio.

 fumarsi il disco e' ampio.
per questo conviene appoggiarsi a chi queste cose le fa bene , grub appunto

"Noixe" <no...@TOGLIMIemail.it> ha scritto nel messaggio 
news:4b431247$0$1144$4faf...@reader1.news.tin.it...

comincia a studiarti come e' fatto l'MBR.
qui trovi qualcosina: 
http://www.compago.it/index.php/manuali/34-linux/64-master-boot-record-mbr
in linea di massima:
il primo settore del disco fisso contiene l'MBR. e' lungo 512 byte di cui 
alcuni sono usati per la tabella delle partizioni, il resto e' il programma 
di avvio.
il BIOS al termine del POST carica l'MBR in una locazione di memoria fissa, 
e lo esegue a partire dal primo byte, non so dirti i vari registri che cosa 
contengano quando il controllo passa al tuo codice, ma forse non e' 
importante, ricordati solo che la CPU e' in modalita' reale.
bye
alfio 

 ciao!
Ciao,
per provarlo devo scaricare i sorgenti e dare makefile (va bene sia Linux 
che Windows)?
Poi dove lo metto il compilato? Il mio pc non ha floppy e mi sa proprio 
che non supporti l'avvio da chiavetta usb.
Ciao

 di caricare il binario del kernel come  se fosse un floppy.
Infatti pensavo di installare VirtualBox (già usata per emulare 
windows :D), o magari mi limito a dare un'occhiata ai sorgenti.
Saluti

 installare. Onestamente non so.Usa Linux...
usa
http://www.mingw.org/
-- 
Saper dimenticare � un arte difficile, a me riesce naturale, rendendomi
un uomo fortunato che vive sempre nel futuro.

 
http://www.mingw.org/
Ho sia Debian che Seven :-D

In effetti non � cos� complicato realizzare i C ci� che desidera 
Noxie, a patto che si seguano alcune regole che si possono intuire 
proprio disassemblando l'BR (Boot Record) del DOS (Ms e non). Facendo 
riferimento all'architettura x86, in effetti, la macchina al bootstrap 
si avvia in modalit� 'real mode' e quindi con indirizzamento a 20 bit; 
si, perch� sarebbe ora di sfatare il fatto che il DOS lavori a 16 bit 
(se cos� fosse non potrebbe indirizzare pi� di 64K ma con un nibble in 
pi� ...). Cosa fa il bios all'avvio? Legge il settore 0 del disco e lo 
copia in memoria all'indirizzo 0000:0c00 (dopo 1k per la sit + 2k di 
dati strutturati) dopodich� normalizza l'indirizzo della prima 
istruzione come xxxx:0100 (00b0:0100) e con un jump alla locazione ne 
va ad eseguire le istruzioni che si preoccuperanno di caricare ed 
avviare il sistema operativo (cio� fa pi� o meno col sistema ci� che 
ha fatto il bios con lui).
In DOS, una delle differenze tra i .exe ed i .com sta proprio nel 
fatto che mentre i primi sono rilocabili, i secondi vengono eseguiti 
sempre a partire dall'indirizzo xxxx:0100 (anche il br) e non possono 
essere pi� grandi di un segmento (stack, dati e codice in 64k).
Quindi per realizzare un codice con le stesse caratteristiche, 
dovrebbe esser (�) sufficiente, in C, scrivere il programma come se 
fosse una funzione da non deve chiamarsi 'main', compilarlo e renderlo 
a locazione fissa (H100) utilizzando un programma come l'exe2bin per 
dos o utilizzando un qualche linker con le giuste opzioni. Inoltre se 
deve prendere i posto del br non deve superare i 512 bytes.
Il codice realizzato, dopo aver svolto i suoi compiti, per far si che 
il bootstrap continui, dovr� recuperare il br originale dal disco, 
copiarlo in memoria con offset 100h e saltargli dentro con un altro 
jump (come se l'avesse fatto il bios).
L'indirizzo della scheda grafica a colori (modo testo) � b800:0000 e 
per scriverci bisogna tenere a mente che a partire dalla posizione 0 i 
byte dispari sono i caratteri visualizzati ed i pari il loro colore 
con: nel nibble inferiore foreground ed in quello superiore il 
background. b000:0000 era l'indirizzo delle vecchie schede hercules 
monocromatiche.
Scusate, ho scritto di getto ma spero di esser stato utile.

 deve prendere i posto del br non deve superare i 512 bytes.
C'è solo una cosa che non mi torna: cosa centra il DOS e i file COM o
EXE
con il bootloader o quale che sia il software che si stà sviluppando?

 
Il DOS l'ho preso come esempio perch� per capire come � strutturato un 
'boot sector' � il meno complicato. Intendo dire che mentre col 
sistema operativo DOS, per verificare ci� che ho detto, � sufficiente 
saper utilizzare uno dei suoi comandi standard (debug), col quale si 
pu� sia leggere e salvare sul disco il settore 0 sia farne il dump in 
assembler, con altri sistemi (windows, linux, ...) la faccenda (a 
causa delle varie protezioni) si fa moolto pi� complicata. In questo 
contesto quindi ho portato come esempio gli EXE per poter affermare 
che il risultato della compilazione del nostro programma non deve 
avere come risultato un codice rilocabile come lo � la stragrande 
maggioranza degli eseguibili attuali. Infine ho usato i COM come 
esempio perch� ha le caratteristiche del pezzo di codice che pu� 
prendere il posto di quello del boot record (l'mbr � ancora un'altra 
cosa). Nel senso che il bios recuperer� il boot record e lo spalmer� 
in memoria a partire dall'offset 100H prima di saltarci dentro 
(proprio come fa il DOS con i COM).
In effetti il DOS non c'entra nulla. L'ho solo preso ad esempio per 
potermi spiegare in modo semplice.
Un saluto.

 
  Ops:
16 bit = 65536 locazioni
20 bit = 1048576 locazioni
(scusate)

 si, perch� sarebbe ora di sfatare il fatto che il DOS lavori a 16 bit 
Per chiarezza: I 16 bit si riferiscono all' ampiezza del data bus,
non dell' address bus.
A.

arm11 ha scritto:

?
cito per x86 real mode:
Call:
(10011010 / 11111111):
viene utilizzata per continuare l'esecuzione dell'indirizzo di inizio 
della routine specificata. Le chiamate possono essere sia dirette che 
indirette e possono riferirsi a routine all'interno dello stesso 
segmento e routine contenute in altri segmenti:
1) chiamata diretta interna al segmento: il registro ip viene salvato 
nello stack e l'indirizzo della routine viene calcolato come la somma 
di ip + uno spiazzamento di 16 bit con segno.
2) Chiamata diretta tra segmenti: il registro cs viene salvato nello 
stack e sostituito dal valore di un segmento di 16 bit, quindi anche 
il registro ip viene salvato nello stack e sostituito con uno 
spiazzamento a 16 bit.
3) chiamata indiretta interna al segmento: il registro ip viene 
salvato nello stack e la locazione desiderata viene calcolata 
aggiungendo ad ip il contenuto di una locazione di memoria o di un 
registro generale.
4) Chiamata indiretta tra segmenti: i registri cs e ip vengono salvati 
nello stack e sostituiti dalle due word che si trovano all'indirizzo 
di memoria specificato dal campo dell'indirizzo effettivo.
Mov:
(100010 DW / 1100011 W / 1011 W REG / 1010000 W /1010001 W / 10001110 
REG-MEM REG / 10001100 REG REG/MEM)
-------
A me sembrano 20 bit sia l'uno sia l'altro.

 pi� ...).
Oh, bene, saranno contenti il C64, Spectrum e MSX che in questo modo
vengono promossi a 16bit :-)

 vengono promossi a 16bit :-)
Si parla di indirizzamento, non di bus.
Lo Z80 indirizza 64K di memoria non paginata con un registro a 16 bit.

Questo dovrebbe permetterti di stampare qualcosa, prima del sistema 
oeprativo
http://www.osdever.net/downloads.php
guarda in fondo, su Kernel 2
Non so pero' poi come potrebbe essere avviato il sistema operativo vero e 
proprio
Ciao
RobertoA

 
http://marcopaviotti.it/index.php/it/markix.html
Complimenti davvero per il lavoro svolto
Molto interessante
Ciao
RobertoA

Roberto Montaruli ha scritto:

Eh gi�, molti confondono la capacit� dell'hardware 
con quella dei sistemisti.

 sistemisti.
Ma la classificazione tra CPU a 8/16/32 bit ha sempre preso come
riferimento la dimensione del bus, non lo spazio di indirizzi raggiugibili.

 riferimento la dimensione del bus,
Io ricordavo la dimensione massima della parola che poteva essere 
processata…

 processata…
In che senso, processata?
Anche sullo spectrum 48k (Z80) ricordo operazioni di LOAD dei dati a 16
bit sui registri BC e DE.. ovvero B+C e D+E, che sono registri a 8 bit.
E nel 68000, registri D0-D7 e A0-A7 a 32 bit, ma il bus dei dati a 16...
l'amiga pertanto e' un ibrido.. 16bit (bus), 24bit (memoria
indirizzabile) o 32bit (registri)? Di fatto, le riviste che leggevo io
(da MC a TGM) la mettevano tra le macchine a 16 bit.

 A me sembrano 20 bit sia l'uno sia l'altro.
No, il data bus e' di 8bit (8088) e 16bit da 8086
fino al 286, 32bit fino al 486 e 64 bit dal pentium
in poi.
Le linee dati NON sono da confondere con le linee
di indirizzo!
In real mode la CPU lavora a 20 bit ma compone
l' indirizzo usando un offset a 16 bit(un registro a 16bit)
e un registro di 'base', sempre di 16bit, che contiene i 4 bit
che vanno a comporre la parte alta dell' indirizzo:
l'hardware si occupa di shiftare tale registro di 16bit
per comporre l' indirizzo fisico a 20 bit.
Da qui la notazione CS:0000, DS:0000 etc. e i mal
di testa per l' uso della memoria (small/large/huge)
Mai lavorato in real mode :-) ?
A.

 (da MC a TGM) la mettevano tra le macchine a 16 bit.
Sono parametri diversi: uno e' la cilindrata, l'altro la capacita di
carico del bagagliaio.
Inoltre se non si lavora in assembly, non e' neanche troppo necessario
conoscere queste informazioni.
Oggi poi ancora meno.

80196@12Mz ha scritto:

Ancora?
Secondo me vi state perdendo. Sto parlando di 
software non di hardware! Ho mai parlato di 
computer? Sto parlando di modalit� di 
indirizzamento. Mai lavorato in real mode? E tu?

PS:
Hai dimenticato i modelli medium, compact e tiny

 In effetti non � cos� complicato realizzare  ...
... comunque se suggerire uno spunto vuol dire 
tutto questo, ragazzi cari ...

 In che senso, processata?
Caricata durante il fetch, in questo caso il "numero di bit" corrisponde 
con l'ampiezza del bus.

 Hai dimenticato i modelli medium, compact e tiny
suno subset dei modelli precedenti :-)

 Mai lavorato in real mode? E tu?
Purtroppo si :-(

 con l'ampiezza del bus.
Ah, ok, stiamo dicendo tutti e tre le stesse cose.

80196@12Mz ha scritto:

Gi�, sono talmente dei subset che se avessi 
provato a linkare un obj di modello large con uno 
di modello compact, il programma si sarebbe 
piantato (constatato personalmente).

80196@12Mz ha scritto:

Sinceramente non ti capisco. La potenzialit� di un 
sistema operativo si dovrebbe misurare in 
relazione alla quantit� di memoria che � in grado 
di gestire non dalla dimensione del dato che offre 
la macchina che lo ospita.

 RobertoA
Grazie mille :)

 ospita.
None. La semplice quantita' di memoria non e' una misura di
potenzialita' di un SO.
Semplificando, una CPU a 64 bit (data bus) con un harware
opportuno che organizzi la memoria a 64bit, puo'
accedere a dati con larghezza di 64bit in un ciclo di
read/write.
Lo stesso processore limitato a 32bit necessitera' invece
di due cicli per leggere il dato a 64bit.
Se si lavora a 8bit saranno necessari 8 cicli...
Va da se' che le performance vanno di pari passo
alla dimensione del data bus :-)
A.

80196@12Mhz ha scritto:

Te sei fuori. Ti preoccupi di non raddoppiare i 
cicli a livello elettrico per acquisire un valore, 
quando dentro un eseguibile ci sono mega di cose 
che non hai scritto e non ti interessano? A queste 
cose pensaci quando devi far 'volare' le cose ma 
in quel caso scrivi in assembler o in C e compila 
senza stub! Con macchine che hanno Ghz di clock 
poi! Una dozzina di anni fa ho scritto un 
diagnostico per le centraline abs delle auto e 
girava egregiamente su un 80186 a 6Mhz. Se di 
mestiere non ti occupi di aerei da guerra o di 
fisica nucleare sprechi solo tempo e fatica. Credi 
a me: � meglio avere tanta memoria a disposizione.

 disposizione.
Mi sa che non hai capito, non si tratta tanto di
ottimizzare i cicli quanto di capire la differenza
tra spazio memoria e l' ampiezza del data bus ;-)
Oltretutto se fai pesante accesso ai dati, e basta
un data base corposo, la differenza a parita' di
quantita' di memoria, tra 32bit e 64 bit (di dato!)
la senti eccome ...

 
Ciao,
ovviamente poi non insister� pi� perch� a questo 
punto mi sembra di remare contro tutto e tutti ma 
secondo il mio pare non � questione di capire o 
non capire. E' ovvio che si noti la differenza; il 
problema � sto notando l'ostinazione a fare 
paragoni lasciando invariato il parametro che 
prediligo io. Nel senso che tutti coloro che mi 
hanno portato un esempio simile, sono partiti dal 
presupposto di parlare di una macchina ben fornita 
di memoria con un so in grado di renderla 
disponibile. Prima, per�, di tentare di 
convincermi dell'importanza della dimensione del 
dato, proverei ad immaginarmi una macchina a 64 
bit con la met� della memoria che, probabilmente, 
raddoppier� il volume dei dati swappati su disco 
(gran bel collo di bottiglia). Non sto dicendo che 
la dimensione del dato non sia importante, solo 
che non � la pi� importante. A questo aggiungo, 
perch� cosa vista e rivista, che la fatica di una 
macchina a fare accesso ai dati � spesso da 
attribuire all'organizzazione della basi dati 
sulle quali gli analisti o i programmatori non 
applicano pi� ne tipologie appropriate ne 
normalizzazioni. Poi? Poi quando i programmi 
invece di essere in 'Run' riescono appena appena a 
camminucchiare, risolvono sostituendo la macchina 
con una pi� veloce e potente. Sar� probabilmente a 
causa dell'ormai tarda et� ma ho avuto la fortuna 
di vedere piccole macchine fare meraviglie 
ospitando dei software ben progettati. sono un 
sostenitore del fatto che le macchine sempre pi� 
potenti abbiano, in qualche modo, 'ammalato' in 
softwaristi.

 di caricare il binario del kernel come  se fosse un floppy.
Scusa ma non sono molto pratico.
Dopo che scompatto mi sposto nella cartella e digito make all?
C'è un Makefile dentro, come si avvia?

 Makefile dentro, come si avvia?
Ho provato a dare il comando make all ma mi dice:
make -C kernel/ all
make[1]: Entering directory `/home/luigi/Desktop/markix/kernel'
main.c:1: error: CPU you selected does not support x86-64 instruction set
main.c:1: error: CPU you selected does not support x86-64 instruction set
make[1]: *** [main.o] Error 1
make[1]: Leaving directory `/home/luigi/Desktop/markix/kernel'
make: *** [kernel.o] Error 2
Ho Debian 5.0 a 64 bit.

 la macchina che lo ospita.
La memoria la riesci a gestire sempre!
Anche con indirizzi di 8 bit.
Io ho avuto la fortuna di scrivere del codice per il processore 8051
(
http://en.wikipedia.org/wiki/Intel_8051
) che ha un bus da 8 bit, ma
che, col meccanismo della memoria paginata, il circuito di cui
disponevo mi permetteva di accedere interamente ad un chip di 512K,
64K per volta.
Non e' la capacita' di indirizzamento che determina la potenza di un
processore, ma le operazioni per secondo.
E con un bus da 8 bit, i cicli consentono di spostare 8 bit alla
volta.

 C'è un Makefile dentro, come si avvia?
quando dai il comando "make" o "make all"  lui cerca il Makefile nella
directory e agisce di conseguenza per compilare
alla fine produce il binario
nella versione 0.1 questo binario si chiama "image.iso" (nelle altre
versioni è stato più appropriatamente chiamato kernel.bin)
il quale va impostato come immagine del disco floppy a VirtualBox (o
qualsiasi altra macchina virtuale)
Es. se usi VirtualBox dopo aver dato "make"
1)Machine -> Settings ->Floppy
2) Mount Floppy -> Image File e gli dai il path del "image.iso"


nel Makefile trovi una riga con scritto CFLAGS...
la quale contiene anche una roba del tipo -march=i386 (il mio pc è a
32bit)
prova a mettere -march=k8 oppure -march=generic (Se lo prende), però
poi la macchina virtuale la devi creare a 64 bit!!
anche se non capisco cosa gli e ne frega a gcc se la macchina nella
quale stà compilando è a 64bit e quella
a cui il compilato è destinato è a 32.. (ammesso sia questo il
problema)

 la macchina virtuale la devi creare a 64 bit!!
Nel Makefile CFLAGS appare solo in queste sezioni:
.S.o:
	@ $(CC) $(CFLAGS) -I ./include/ -o $@  $< 
.c.o:
	@ $(CC) $(CFLAGS) -I ./include/ -o $@  $< 
dove dovrei mettere -march=miarchiettettura (forse dovrei mettere amd64, 
almeno quello è il nome che appare nel pacchetto nell'immagine netinst 
che ho scaricato)
Ho scaricato la versione 0.6, sono curioso di vedere il progetto più 
completo :-D

 
Ciao,
si si ma a che prezzo? Visto che si parlava di 
perfomance, qui il tempo lo spendi tutto a 
multiplexare i banchi di ram. Se non fosse per 
l'enorme perdita di tempo ad oggi nessuno se ne 
sarebbe preoccupato ed avremmo ancora i pc con le 
schede di memoria 'espansa'! Non � che vi siete 
messi d'accordo per confondermi le idee, vero? :-)

 siete messi d'accordo per confondermi le idee, vero? :-)
Ma no, ti stiamo solo dicendo che i bit in questione
sono relativi alla profondita' del dato, non
dell' indirizzo.
Ciao
A.

 completo :-D
nella versione 0.6 la variabile in questione è in "make.rules"
in ogni caso prova anche con -m32 al posto di -march=i386 e poi metti
il binario
come immagine floppy per una macchina a 32bit
P.S.: altri consigli sono ben accetti :)

Il Sat, 16 Jan 2010 11:04:56 -0800, Markix ha scritto:
 > P.S.: altri consigli sono ben accetti :)
Allora, mettendo -march=k8, generic, i386, o qualsiasi altra cosa ottengo 
errori di incompatibilità, quindi la lascio i386:
$ make all
make -C kernel/ all
make[1]: Entering directory `/home/luigi/Desktop/markix/kernel'
make[2]: Entering directory `/home/luigi/Desktop/markix/kernel/interrupt'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/luigi/Desktop/markix/kernel/interrupt'
make[2]: Entering directory `/home/luigi/Desktop/markix/kernel/arch'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/luigi/Desktop/markix/kernel/arch'
make[2]: Entering directory `/home/luigi/Desktop/markix/kernel/scheduler'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/luigi/Desktop/markix/kernel/scheduler'
make[2]: Entering directory `/home/luigi/Desktop/markix/kernel/memory'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/luigi/Desktop/markix/kernel/memory'
make[1]: Leaving directory `/home/luigi/Desktop/markix/kernel'
make -C boot/ all
make[1]: Entering directory `/home/luigi/Desktop/markix/boot'
nasm -fbin boot.asm -o boot.bin
make[1]: Leaving directory `/home/luigi/Desktop/markix/boot'
ld -Bstatic -nostdlib -nostartfiles -nodefaultlibs -e _start --oformat 
binary \
                -o kernel.bin start.o kernel/*.o \
                kernel/arch/*.o kernel/interrupt/*.o kernel/scheduler/*.o 
kernel/memory/*.o \
                -Ttext 0x10000 -Map kernel.map
ld: i386 architecture of input file `kernel/arch/intel.o' is incompatible 
with i386:x86-64 output
ld: i386 architecture of input file `kernel/arch/interrupt_handlers.o' is 
incompatible with i386:x86-64 output
ld: i386 architecture of input file `kernel/arch/ioport.o' is 
incompatible with i386:x86-64 output
ld: i386 architecture of input file `kernel/scheduler/proc.o' is 
incompatible with i386:x86-64 output
ld: i386 architecture of input file `kernel/memory/memory.o' is 
incompatible with i386:x86-64 output
make: *** [all] Error 1

 messi d'accordo per confondermi le idee, vero? :-)
Qui si parla di programmazione di software e non di hardware.
Se tu hai una piattaforma di sviluppo con dei limiti e ti viene
richiesto di svilupparci sopra, devi tener conto di quei limiti e non
oltrepassarli. Non ci vedo niente di strano in questo.
E comunque nessuno vuole confondere le idee, ma solo mettere in chiaro
alcuni aspetti che oggigiorno si tende a trascurare perche' non ci
sono piu' quei limiti imposti dall'hardware che c'erano una volta.