Newsgroup: it.comp.lang.pascal
Titolo: Data Segment Too Large

Salve a tutti,
ho un problema   :-[#]
Devo dichiarare una serie di array di byte da 65500 (const  : array
[1..65500] of byte =( bla,bla,bla); ). Ovviamente la loro somma esce dagli
spazi che mi sono concessi di default e il compilatore mi dice 'DATA SEGMENT
TOO LARGE'. Il comando new l'ho imparato da poco ma non so se è possibile
usarlo in questo caso. Qualcuno potrebbe dirmi come superare il limite dei
65520?.  Grazie
--
ThE DArkNeSS iS JuST DaRK

 ha scritto nel messaggio
news:TwyD8.49991$5k4.1...@twister2.libero.it...


 ha scritto nel messaggio
news:TwyD8.49991$5k4.1...@twister2.libero.it...


 > TOO LARGE'. Il comando new l'ho imparato da poco ma non so se č



Usa una lista concatenata, strutturata dinamicamente per risolvere il tuo
problema :-)
In altre parole, fai ricorso all'uso dei puntatori... in questo modo evadi
il limite del 64k del segmento e entri in quello dei 16Mb della memoria
estesa.
Cordialmente, Cooper.


Esistono

> Esistono
Dovrebbero sfruttare emm386 prensete sotto dos, io nn l'ho mai usate ma
facendo qualche ricerca ho trovato un bel po di librerie

bello bello..
quindi ci devono essere anche per Turbo C++ presumo..
bello bello..
non sapevo.. bello bello
Thanks, Cereal
"ReDiCuori" <redicu...@NOSPAMlibero.it> ha scritto nel messaggio
news:j_bE8.42107$CN3.1...@news2.tin.it...


 il compilatore mi dà il noto errore.
Intendevo dire ke questo accade quando tento di compilare la unit.


il fatto e' che quando viene compilato il codice, il tp divide le varie
cose in tre segmenti: codice, data e stack. Ogni segmento come
sempre non puo' essere piu' grosso di 64kb (infatti per il codice
ci sono chiamate `near' e `far') e le tue costanti riempiono in un
sol colpo tutto il segmento data.  L'unica soluzione e' caricarle
a run-time nel resto della memoria, cioe' nella heap dove hai
a disposizione fino a 640kb (utopia)... cmq c'e' sempre la limitazione
sulla dim. massima a 64kb... pero' puoi fare 10 array :-)
Le costanti cmq non andrebbero usate come variabili di normale
utilizzo: come buffer per leggere da file si e' soliti proprio allocare
dinamicamente quello che serve:
type
 buffer: array[0..65519] of byte;
var
 p : ^buffer;
...
getmem(p, <dimensione>);
blockread (f, p^, dimensione);
{ `p^' indica la "variabile" puntata da p }
... { uso del buffer }
freemem(p, <dimensione>);
{ alternative con New/Dispose }
--
Dreadnaut
(Life would be easier if I had the source code)

 cose in tre segmenti: codice, data e stack. Ogni segmento come
Manca il segmento programmi :P Quindi sono 4, non 3 :-)
Cooper

> Manca il segmento programmi :P Quindi sono 4, non 3 :-)
?? mmmh... forse non tiamo parlando della stessa cosa...
Ci sono solo tre tipi di segmenti gestibili dai processori x86, e sono
DATA CODE e STACK: sono distinzioni sulle zone di memoria che sono
state implementate nell'architettura dei processori per evitare che
programmi accedessero a zone di memoria nel modo sbagliato: ad esempio
operazioni di push e pop vengono eseguite solo su segmenti stack.
[ chi lavora coll'asm lo sapra' spiegare sicuram. meglio di me :-) ]
Il tp divide nell'eseguibile le varie unit di diversi segmenti code, ad
ognuno dei quali va il nome della unit. Per il programma stesso viene dato
il nome definito dal famoso "Program <nome>" ad inizio file... e' l'unica
utilita che e' rimasta al comando :-) altrimenti di default viene chiamato
"PROGRAM" [asp forse ti riferivi a questo come `segmento programmi' ? ]
Questo e' un pezzo di un .map fatto dal linker del tp, che indica in quali
parti e' diviso logicamente l'eseguibile al caricamento:
 Start  Stop   Length Name               Class
 00000H 01775H 01776H PROGRAM            CODE
[...]
 036B0H 06D0EH 0365FH Graph              CODE
 06D10H 07DE3H 010D4H System             CODE
 07DF0H 0905FH 01270H DATA               DATA
 09060H 1904FH 0FFF0H STACK              STACK
 19050H 19050H 00000H HEAP               HEAP
queste poi sono info di debug... nell'exe i nomi non compaiono
e beh credo che individuare ad occhio le varie parti su un edit.
esadecimale sia un lavoro tipo schermata verde alla matrix :-)
mmmh poi forse ti riferivi a qlcs altro e' ho postato un mex inutile :-)
vabbeh...
ciao



No mi riferivo al segmento PROGRAM che si affianca a DATA, STACK e CODE. In
tutto l'area di memoria segmentata è appunto di 256 Kb.
Il PROGRAM del pascal che si mette come prima riga, non c'entra nulla con
questo discorso .-)   Ho avuto la conferma anche andando a rivedere gli
appunto di scuola, nel volume SISTEMI :-)
Cooper.

 nel volume SISTEMI :-)
mmmh Intel Opcode Help...  mi fido di piu' ;-)
cmq nel mess iniziale mi interessava piu' che altro spiegare la differenza
fra i tre tipi di segmento... il tp non mette niente nel segmento extra.
