Subject: 64k limit ?????? data segment error ....
the...@usa.net
HI,
I`m getting a "data segment too large" error and I think it`s because I`m
over the 64k limit. I used 25 arrays and a total of 383 objects. When the
compiler gets to the 15th array ( or the 255th object ) I get the error.
The array`s are made up of constant strings ( not integers ). Does anyone
know any way to stop this error ??????
THePrO
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Istvan Albert
Pedt Scragg
In article <8664756...@dejanews.com>, the...@usa.net writes
>HI,
>
>I`m getting a "data segment too large" error and I think it`s because I`m
>over the 64k limit. I used 25 arrays and a total of 383 objects. When the
>compiler gets to the 15th array ( or the 255th object ) I get the error.
>The array`s are made up of constant strings ( not integers ). Does anyone
>know any way to stop this error ??????
>
dynamically use memory on the heap. It is *not* Possible to have a data
segment of more than 64K.
--
Pedt Scragg <postm...@pedt.demon.co.uk>
In principle, is there uncertainty that
Heisenberg was working his best in chaos?
=========================================
Asbjørn
Pedt Scragg wrote:
>
> In article <8664756...@dejanews.com>, the...@usa.net writes
> >HI,
> >
> >I`m getting a "data segment too large" error and I think it`s because I`m
> >over the 64k limit. I used 25 arrays and a total of 383 objects. When the
> >compiler gets to the 15th array ( or the 255th object ) I get the error.
> >The array`s are made up of constant strings ( not integers ). Does anyone
> >know any way to stop this error ??????
> >
> Only by setting up pointers to arrays and using GetMem / New to
> dynamically use memory on the heap. It is *not* Possible to have a data
> segment of more than 64K.
That kinda depends on the compiler... Notise the cross posting... But,
since
he included .tpascal, is assume that's what he's got. And then, the
first solution
would be pointers.
type
fooObject = object
...
end;
fooObjectPtr = ^fooObject;
var
fooArray: array[1..1000] of fooObjectPtr;
begin
new(fooArray[1]);
...
dispose(fooArray[1]);
end.
Something like that. You might alter it, if you use virtual methods
--
- Asbjørn / Lord Crc
Heiko Lüttge
the...@usa.net schrieb im Beitrag <8664756...@dejanews.com>...
> HI,
>
> I`m getting a "data segment too large" error and I think it`s because I`m
> over the 64k limit. I used 25 arrays and a total of 383 objects. When the
> compiler gets to the 15th array ( or the 255th object ) I get the error.
> The array`s are made up of constant strings ( not integers ). Does anyone
> know any way to stop this error ??????
>
>
> THePrO
>
> -------------------==== Posted via Deja News ====-----------------------
> http://www.dejanews.com/ Search, Read, Post to Usenet
>
put the arrays into a record and allocate the record dynamically.
old:
type
a1: array[1..] of
a2:..
new:
type
trec = record
a1: array[1..] of
a2:..
end; { trec }
var
rec: ^trec;
begin
new (rec);
use the data just like rec^.a1[5]
dispose(rec).
Heiko
lue...@sunpool.cs.uni-magdeburg.de
Kim Robert Blix
the...@usa.net once said:
>HI,
>
>I`m getting a "data segment too large" error and I think it`s because I`m
>over the 64k limit. I used 25 arrays and a total of 383 objects. When the
>compiler gets to the 15th array ( or the 255th object ) I get the error.
>The array`s are made up of constant strings ( not integers ). Does anyone
>know any way to stop this error ??????
You can :
1) Split the data into different units.
2) Use pointers and getmem.
3) Make the strings smaller (Mystring : String[size]) if possible.
Hope this helps
--
Kim Robert Blix ( kb...@sn.no & http://home.sn.no/~kblix )
"How do you shoot the devil in the back?"
"What if you miss?" -Verbal Kint
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Sundial Services
>I`m getting a "data segment too large" error and I think it`s because I`m
>over the 64k limit. I used 25 arrays and a total of 383 objects. When the
>compiler gets to the 15th array ( or the 255th object ) I get the error.
>The array`s are made up of constant strings ( not integers ). Does anyone
>know any way to stop this error ??????
In 16-bit Delphi, the data-segment and the stack occupy a single 64K area.
For this reason, most things are dynamically allocated. For example, you can
define a "Global" object in a unit that is shared by all other application
modules.
The main program creates "Global" when the program starts and destroys it when
the program ends.
There is also a limitation that no single object can be larger than 64K.
However, if you define "Global" as a Delphi class, you can design whatever
implementation you need in that one module and the rest of the program can
ignore the technical details. There are a variety of container-classes
available.
Sundial Services
>>1) Split the data into different units.
>This must me one of the most common false advices in this group. It does
>not help as the data segment is global.
>>2) Use pointers and getmem.
>>3) Make the strings smaller (Mystring : String[size]) if possible.
>>
>Osmo
What I usually do is to define one "global" object. It's actually a class.
It's created when the program starts and destroyed as it goes away.
All of the things that the various units of the program need to talk among
themselves and to each other are stored in Global. When the things that are
global need to be larger than 32K or so (even in Win95.. transportability is
still important to me), it becomes a method. Voila, now the class hides all
of the details of physically locating and storing/retrieving the global
information -- exactly, of course, as a class ought to do.
It works. Even in Win95-land, it works.
Osmo Ronkanen
David Firth
Amusing, isn't it? How many times do we have to muddle through someone's
post on the 64K limit? The first thing any programmer needs to do is
understand their tools and their "limitations." The second is to
understand the problem they want to solve and design an appropriate
solution.
For goodness sake, master using dynamic memory -- the heap wasn't designed
into the compiler for the heck of it. Think through memory use and
appropriately apply the available data types. For example, a programmer
who uses an unqualified string (equiv to string[255]) for a simple prompt
for a short string is wasting memory. Now for most app's, the waste isn't
noticed because there is memory to spare. However, if the program needs
to handle large amounts of data, thinking through the use of data types
and using dynamic memory should be part of the design process.
Applied once, qualifying string lengths won't do much. But in a larger
construct such as an array, the savings multiplies.
--
------------------------------------------------------------------
David Firth N8PTK ! 52 45 41 4C 43 4F 4D 50 55 54 45
! 52 53 48 41 56 45 4F 4E 4C 59 38
djf...@freenet.columbus.oh.us ! 42 49 54 53 4D 45 43 38 32 30 31
Maria van der Plas
Dear David Firth,
Even you started one day programming. Please don't be a wiz kid but help
starters, that's what these groups are about. THERE ARE NO STUPPID
QUESTIONS, BUT THERE ARE SIMPLE ANSWERS.
Don't you remember your parents helping you with your first steps......
Niek Breur
Alan M. Evans
Maria van der Plas wrote:
> THERE ARE NO STUPPID QUESTIONS
Stick around.
AME
David Firth
Maria van der Plas (spy_...@bigfoot.com) wrote:
: Even you started one day programming. Please don't be a wiz kid but help
: starters, that's what these groups are about. THERE ARE NO STUPPID
: QUESTIONS, BUT THERE ARE SIMPLE ANSWERS.
Point taken. Dynamic memory was a mystery at one time for me too. However,
the 64K limit is pretty clearly spelled out in the doc's. RTM, you know.
: Don't you remember your parents helping you with your first steps......
I was pretty young. I bet you don't remember either.
Mike Copeland
> >>You can :
> >>
> >>1) Split the data into different units.
>
> >This must me one of the most common false advices in this group. It does
> >not help as the data segment is global.
>
>
> Isn't it possible for an executable to declare more than one data
> segment (or am I talking rubbish).
Insofar as TP/BP is concerned, this is rubbish. 8<}} TP/BP allows
the use of only a single Data Segment, which it constructs from all the
(referenced) Var data declared in all the referenced Units and source of
the program. You are allowed only (that infamous) 64K of such program
data - that which is declared as Var data, that is.
However, some of that Var data can be Pascal pointers, so the actual
"data" used by the program can be allocated (stored) on the Heap - giving
the program capability to "use" much more than 64K bytes of "data". You
must know how to work with Pascal pointers, though.
Also, procedure-local data (Vars declared inside subprograms) can be
as much as has been reserved for the Stack - also a 64K total limit
there. It's thus possible to use almost 128K of Var data, given the
structure of the program and how much local data is declared in higher
level subprograms.
Finally, there's the concept called Smart Linking, where only
_referenced_ Var data is actually linked into the programs (which becomes
part of that 64K limit), and it's often likely that all the Var date
declared in a Unit isn't truly referenced by the program Using the Unit.
A feature in TP/BP known as "Var blocks" (declaring data in multiple
Vars), "grouped" according to the programs which Use the Unit) allows the
Smart Linker to see only pertinent data when doing the link. This
valuable technique isn't simple or easy to use, since one must know a lot
about how global Unit data is used and by what other programs and Units.
Whew...
> I don't know of any technical reason why the app can't declare more
> than one data segment..... enlighten me.
There may not be any _technical_ reason, but that's how Borland
implemented the data aspect of their Pascal systems. I believe it's so
the optimize data referencing by loading once and maintaining the
contents of a hardware register throughout the duration of the program's
execution.
>
> I would think no more than 64k of data per unit, yes, but I'm sure
> I've made DOS apps with more than 64k overall.
Yes, but not with TP or BP, I'm sure...8<}}
Martin Harvey
ronk...@cc.helsinki.fi (Osmo Ronkanen) wrote:
>In article <33a6a747...@news.sn.no>, Kim Robert Blix <kb...@sn.no> wrote:
>>
>>You can :
>>
>>1) Split the data into different units.
>This must me one of the most common false advices in this group. It does
>not help as the data segment is global.
Oh really????
Isn't it possible for an executable to declare more than one data
segment (or am I talking rubbish).
I don't know of any technical reason why the app can't declare more
than one data segment..... enlighten me.
I would think no more than 64k of data per unit, yes, but I'm sure
I've made DOS apps with more than 64k overall.
Martin Harvey.
***********************************************
Martin Harvey
Uni email:
6D 63 68 32 34 40 63 61 6D 2E 61 63 2E 75 6B
Home email:
6D 63 68 32 34 40 68 61 72 76 65 79 32 37 2E 64
65 6D 6F 6E 2E 63 6F 2E 75 6B
Decode the HEX back into ASCII chars.
Uni web pages: http://www-stu.pem.cam.ac.uk/~mch24/
***********************************************
Klaus Hartnegg
Martin Harvey (mc...@harvey27.demon.co.uk) wrote:
: >It does not help as the data segment is global.
: Oh really????
: Isn't it possible for an executable to declare more than one data
: segment (or am I talking rubbish).
Yes, but we were talking about Borland Pascal and unfortunately
here it's true: there is one data segment and all units use that
same data segment, so the total amount of all global variables
can not exceed 64k.
Check my home page for a few modern pascal compilers that
don't have such limitations. Some are even free and
available for more than just Dos.
Klaus
--
Klaus Hartnegg, Institut fuer Biophysik, Hansa-Strasse 9a, D-79104 Freiburg
hart...@uni-freiburg.de http://www.brain.uni-freiburg.de/~klaus/
Klaus Hartnegg
the...@usa.net wrote:
: I`m getting a "data segment too large" error and I think it`s because I`m
: over the 64k limit.
Borland Pascal 64k Limit FAQ
----------------------------
I'm planning to post this FAQ whenever someone asks how to
use more than 64k variables in a Borland Pascal program.
Unless of course it's asked several times a day, then I'll send
it a bit less frequently than that :-)
If you have any comments/suggestions/corrections please tell me.
Q: Can a Borland Pascal program use static variables
with more than 64 kilobytes?
A: No!
Q: You said *static* variables. Are there other and does it work with them?
A: Yes, see "Is there a Solution" below, but first read the rest here
to avoid wasting time trying other alternatives, because they
all do not work.
Q: Does it help to split a large array in several small arrays
(all parts smaller than 64k, but in total larger than 64k) ?
Q: No!
Q: Does it help to declare some of the variables in a Unit?
A: No!
Q: Does it help to declare some in the Implementation Part of a unit?
A: No!
Q: Does it help to use the protected mode of Borland Pascal 7 ?
A: No!
Q: Are you sure ??
A: Yes !!
Q: Why ??
A: All programs written in Borland Pascal use only one segment for all
variables and the Intel 80xxx processors are limited to 64k per segment.
Q: That's silly!!
A: Tell Borland!! (Or Intel or both).
Q: Is there a Solution ?
A: Yes! There are two solutions:
1) don't use *STATIC* variables for storing huge amounts of data.
This will allow to store more than 64k in total, but never
more than 64k in *one* array, so yes you must split them but
that alone doesn't help. You must also make them dynamic.
2) use another Compiler: there are a few Pascal compilers
available that are more or less Borland compatible and that
don't have these limitations (they are 32-bit Compilers).
Q: Why is Borland Pascal not a 32-bit Compiler?
A: It's too old. Tell Borland you want a new version.
Q: What is non-static memory?
A: For example Heap, XMS, EMS, ...
Heap is directly accessible, XMS needs a driver (himem.sys),
EMS too (HIMEM.SYS + EMM386.EXE) and is not commonly available
on all computers, so better use XMS instead of EMS.
Q: What is the Heap ?
A: Heap is in real mode all free memory below the 640 kilobyte limit,
in protected mode (available in Borland Pascal 7 only) all free
memory below the 16 Megabyte limit (and usually *ALL* free memory
but we're only talking about Borland Pascal here).
Q: How can I use the heap?
A: Memory on the heap can only be accessed with pointers.
Try this example, then adapt the principle to your programs:
type
arr = array [1..30000] of longint; { this is your data }
arrptr = ^arr; { that's a pointer to the data }
var
data : arrptr; { this is such a pointer variable }
begin
if memavail < sizeof(arr) then halt; { check if enough memory available}
new (data); { allocate the memory }
for i := 1 to 30000 do data^[i]:=0; { use it, note the ^ sign here !! }
dispose (data); { release the memory }
end.
Note: instead of data you could also do
var
data : array [1..10000] of arrptr;
Q: Does this have disadvantages
A: Yes! It's slower and a bit dangerous.
Q: Using the heap is dangerous?
A: Yes!
Double-check that you *always*, I mean really *ALWAYS* allocate
all heap memory before you use it. Otherwise you will see the same
thing happening that we are used to from C programs:
in Windows it's called "General Protection Violation", other
systems call it "Protected Mode Exception #13" or similar.
In real mode the program will usually not cause such an error,
it will just silently overwrite imporant things like other data, the
program itself, other programs, DOS or whatever it finds in memory.
This can cause anything from no negative effect at all to completely
freezing the PC with only the reset button and power switch still
operational. In extreme cases it may also cause data on the hard
disk to be overwritten. That's very unlike”ly but in theory possible.
Q: How can I use XMS memory?
A: See http://www.brain.uni-freiburg.de/~klaus/pascal/sources/
for a unit that allows to use XMS.
Q: What about other Pascal compilers?
A: Check FPK-Pascal and GNU-Pascal.
Both are free 32-bit Pascal compilers available for DOS
that are more or less Borland compatible.
If you want a Pascal compiler for Linux or OS/2, the two same compilers
are available for these operating systems too plus a few more, see
http://www.brain.uni-freiburg.de/~klaus/pascal/web-list.html
Q: This sounds as if the FAQ writer doesn't like Borland Pascal, right?
A: Wrong, I *love* it and use it all the time,
but I *hate* Borland for not offering new versions.
Q: What about Delphi?
A: It's not available for DOS,
it's not available for Linux,
it's not availalbe for OS/2.
Please send additions/comments/complaints to this FAQ
to Klaus Hartneg, hart...@uni-freiburg.de
R.E.Donais
mc...@harvey27.demon.co.uk (Martin Harvey) wrote:
>ronk...@cc.helsinki.fi (Osmo Ronkanen) wrote:
>
>>In article <33a6a747...@news.sn.no>, Kim Robert Blix <kb...@sn.no> wrote:
>>>
>>>You can :
>>>
>>>1) Split the data into different units.
>
>>This must me one of the most common false advices in this group. It does
>>not help as the data segment is global.
>
>Oh really????
>
>Isn't it possible for an executable to declare more than one data
>segment (or am I talking rubbish).
Yep, you're definitely talking rubbish!
>
>I don't know of any technical reason why the app can't declare more
>than one data segment..... enlighten me.
I don't know if it's technical enough to suit you, but multiple
data segments weren't designed or implemented in any version of
TP/BP.
>
>I would think no more than 64k of data per unit, yes, but I'm sure
>I've made DOS apps with more than 64k overall.
Yes Martin, it may sound reasonable, but that doesn't make it
fact, and fact is that TP defines only _one_ data segment for
the entire program!
It might appear that you had more than 64k, Martin. While local
variable allocated on the stack and dynamic variables allocated
on the heap would allow more than 64k of data, but your TP/BP
program would never have more than _one_ 64k data segment.
If you are using any version of Turbo Pascal, then regardless of
what you may "think", your app had only data segment. You don't
have to take our word for it. Just define a few units that
declare large data structures and see how many you can link into
your program.
Don't forget to reference the structures or the smart linker
will not include them. I guess defining data structures that
are never used could be another way that would give you the
illusion of more than one 64k data segment.
...red
--
Support the anti-Spam amendment
Join at http://www.cauce.org/
Sundial Services
In article <867201470.6952.3...@news.demon.co.uk> mc...@harvey27.demon.co.uk (Martin Harvey) writes:
>>>1) Split the data into different units.
>>This must me one of the most common false advices in this group. It does
>>not help as the data segment is global.
>Oh really????
>Isn't it possible for an executable to declare more than one data
>segment (or am I talking rubbish).
>I don't know of any technical reason why the app can't declare more
>than one data segment..... enlighten me.
>I would think no more than 64k of data per unit, yes, but I'm sure
>I've made DOS apps with more than 64k overall.
Each application instance, in 16-bit Windows, has one data segment assigned to
it in which is stored its global variables, its stack, and a small amount of
Windows housekeeping information (the local heap).
This is a hard limit. Everything else you use must be dynamically allocated
and dynamically freed -- and this is, indeed, how one obtains the use of the
"additional data segments" you speak of.
A program may have a hundred data-segments under its purview (more if it's
from Microsoft ;-)) but each instance has only one stack segment.
Martin Harvey
mrc...@primenet.com (Mike Copeland) wrote:
>> >>You can :
>> >>
>> >>1) Split the data into different units.
>>
>> >This must me one of the most common false advices in this group. It does
>> >not help as the data segment is global.
>>
>> Oh really????
>>
>> Isn't it possible for an executable to declare more than one data
>> segment (or am I talking rubbish).
> Insofar as TP/BP is concerned, this is rubbish. 8<}} TP/BP allows
>the use of only a single Data Segment, which it constructs from all the
>(referenced) Var data declared in all the referenced Units and source of
>the program. You are allowed only (that infamous) 64K of such program
>data - that which is declared as Var data, that is.
<snip>
Ah right. Well I've been using dynamic variables to get round these
problems for years. It often the best way too... you don't grab huge
amounts of memory, but make efficient use of what you have :-)
>> I don't know of any technical reason why the app can't declare more
>> than one data segment..... enlighten me.
> There may not be any _technical_ reason, but that's how Borland
>implemented the data aspect of their Pascal systems. I believe it's so
>the optimize data referencing by loading once and maintaining the
>contents of a hardware register throughout the duration of the program's
>execution.
Quite likely. If I remember the segment registers on the 8086 are
CS,DS,SS,ES (and of the 386 FS & GS). It seems to me that a sensible
register allocation strategy would keep DS and SS constant for the
data and stack segments, and then only change CS on far calls to allow
for more than 64K of code, and use ES as the segment register for
dereferencing pointers.
>> I would think no more than 64k of data per unit, yes, but I'm sure
>> I've made DOS apps with more than 64k overall.
> Yes, but not with TP or BP, I'm sure...8<}}
Nope... it wasn't. I used a Modula-2 compiler, and looking back at the
various map files and disassemblies I have, it does seem to be doing a
few rather odd things with the segment registers. This rather
intrigues me, so I'll look into it further.
many thanks for the help :-)
Asbjørn
> >>
> >>You can :
> >>
> >>1) Split the data into different units.
>
> >This must me one of the most common false advices in this group. It does
> >not help as the data segment is global.
>
> Oh really????
>
> Isn't it possible for an executable to declare more than one data
> segment (or am I talking rubbish).
Yes you can
> I don't know of any technical reason why the app can't declare more
> than one data segment..... enlighten me.
They just didn't choose to do it, or something...
Martin Harvey
rdo...@southeast.net (R.E.Donais) wrote:
>mc...@harvey27.demon.co.uk (Martin Harvey) wrote:
>>ronk...@cc.helsinki.fi (Osmo Ronkanen) wrote:
>>
>>>In article <33a6a747...@news.sn.no>, Kim Robert Blix <kb...@sn.no> wrote:
>>>>
>>>>You can :
>>>>
>>>>1) Split the data into different units.
>>
>>>This must me one of the most common false advices in this group. It does
>>>not help as the data segment is global.
>>
>>Oh really????
>>
>>Isn't it possible for an executable to declare more than one data
>>segment (or am I talking rubbish).
>Yep, you're definitely talking rubbish!
>>
>>I don't know of any technical reason why the app can't declare more
>>than one data segment..... enlighten me.
>I don't know if it's technical enough to suit you, but multiple
>data segments weren't designed or implemented in any version of
>TP/BP.
Ahh.... well I wasn't using TP or BP. I was using a Modula-2 compiler
that did some very odd things with segmentation.....
Martin H.
Martin Harvey
news-...@sundialservices.com (Sundial Services) wrote:
This is what I suspect. The reason I think Borland only used on Data
segment is that it complicates things considerably to have more than
one, and it violates the MS and Borland linker conventions to have
more than one. Having said that... I was using a proprietrary linker..
Alan M. Evans
Klaus Hartnegg wrote:
> Q: How can I use the heap?
> A: Memory on the heap can only be accessed with pointers.
> Try this example, then adapt the principle to your programs:
> type
> arr = array [1..30000] of longint; { this is your data }
> arrptr = ^arr; { that's a pointer to the data }
> var
> data : arrptr; { this is such a pointer variable }
> begin
> if memavail < sizeof(arr) then halt;
^^^^^^^^
Should be MaxAvail.
AME
Mike Copeland
> >> >>1) Split the data into different units.
> >>
> >> >This must me one of the most common false advices in this group. It does
> >> >not help as the data segment is global.
> >>
> >
>
>
> >Pardon my french but this is bull.
>
> Then I tested this:
> ---------------------------------------------------
> Unit Test1;
> Interface
> Var array1: Array[0..65535] of byte;
> Implementation
> End.
> ---------------------------------------------------
> Unit Test2;
> Interface
> Var array2: Array[0..65535] of byte;
> Implementation
> End.
> ---------------------------------------------------
> Program Testit;
> Uses Test1,Test2;
> Var Counter : Word;
> Begin
>
> End.
> ---------------------------------------------------
>
> Ok.. This compiles nicely.. and so it does if you use one of the arrays.. As
> soon as you try to poke something into the 65536'th byte though, you get a "data
> segment too large" error.. I fold. I was pretty sure it was possible, but I
> havent used this way of "memory allocation" in ages. hehe..
This test of yours, while it may _compile_, isn't at all valid - none
of the Var declarations in the Units is linked into the program, since
there are no _references_ to any of the data. Apparently you don't
understand the concept of the Data Segment, Unit vars, scoping, or how
the Smart Linker works - and all you've done here is compile a "dummy"
program which has no data whatsoever. So your point is moot.
The whole discussion in this thread has been about the (very real) 64K
Data Segment limit imposed by Borland's implementations of TP and BP. No
matter how you slice/dice it, such a program cannot have more than 64K of
Var data, wherever it's declared, because the Linker moves _all_ data
into a single address segment (which is limited to the 64K address space
of the PC architecture). Other compilers and other implementations have
overcome this, but they do so by having _multiple_ Data Segments (just as
TP/BP can have multiple Code Segments...but only 1 Data Segment). Now,
this Smart Linker does a nice job of analyzing all Used Units, their
referenced procedures & functions, and the _referenced_data_ in all.
Some of the Units may declare more than 64K data (or multiple Units may
declare what amounts to more than a total of 64K of Var data, but
_it's_what_the_linker_binds_into_the_EXE_ that matters -n and which can't
exceed 64K bytes.
Your "test" demonstrates this very point, because if you were to
generate a .MAP file with your compile, you'd see that virtually _no_
Data is used by the program, even though there is a lot of _declared_
data - because no references are made to anything you've declared. To
further prove this point - because I don't except this discussion to "get
through" to you - add some statements in your test program which
references the "Array1" and "Array2" variables...and see what happens.
pa...@premier1.net
Kim Robert Blix wrote:
>>> You can :
>>>1) Split the data into different units.
>> This must me one of the most common false advices in this group. >> It does not help as the data segment is global.
> Pardon my french, but that us bull.
Unfortunatly, at least for TURBO and BORLAND Pascal, it is NOT.
The Memory model choosen by Borland for Pascal allows multiple
CODE segments, but only 1 global DATA segment.
Each unit gets it's own CODE segment, but shares a common 64K
DATA segment. The only way around it is:
1. Don't over use Global Variables. They can be dangerous and a
waste of resouces. Declare your variables within the procedures
that need them, and pass them as needed.
2. Use Dynamic Memory and Pointers.
3. Dump Borland and DOS and switch to OS/2 and Speed Pascal or
Virtual Pascal, for a full 32 bit flat memory model.
pa...@premier1.net
pa...@premier1.net
Kim Robert Blix
>> >>You can :
>> >>
>> >>1) Split the data into different units.
>>
>> >This must me one of the most common false advices in this group. It does
>> >not help as the data segment is global.
>>
>
Then _I_ Wrote :)
End.
---------------------------------------------------
Kim Robert Blix
mc...@harvey27.demon.co.uk (Martin Harvey) once said:
>ronk...@cc.helsinki.fi (Osmo Ronkanen) wrote:
>
>>In article <33a6a747...@news.sn.no>, Kim Robert Blix <kb...@sn.no> wrote:
>>>
>>>You can :
>>>
>>>1) Split the data into different units.
>
>>This must me one of the most common false advices in this group. It does
>>not help as the data segment is global.
>
Pardon my french, but that us bull.
Pedt Scragg
In article <33b12820...@news.sn.no>, Kim Robert Blix <kb...@sn.no>
writes
>mc...@harvey27.demon.co.uk (Martin Harvey) once said:
>
>>ronk...@cc.helsinki.fi (Osmo Ronkanen) wrote:
>>
>>>In article <33a6a747...@news.sn.no>, Kim Robert Blix <kb...@sn.no> wrote:
>>>>
>>>>You can :
>>>>
>>>>1) Split the data into different units.
>>
>>>This must me one of the most common false advices in this group. It does
>>>not help as the data segment is global.
>>
>
>Pardon my french, but that us bull.
>
>
want more variables you *do* need to use the heap, in TP/BP.
Note: I'm assuming TP/BP Compiler as this is X-Posted to c.l.p.b
>--
> Kim Robert Blix ( kb...@sn.no & http://home.sn.no/~kblix )
>
> "How do you shoot the devil in the back?"
> "What if you miss?" -Verbal Kint
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Duff SigSep (SigSep = "Dash" "Dash" "Space")
--
Pedt Scragg <postm...@pedt.demon.co.uk>
In principle, is there uncertainty that
Heisenberg was working his best in chaos?
=========================================
Pedt Scragg
In article <90E7F85540F75B10.B0AEDBBBD1A3FD2F.7959322B0E941539@library-
proxy.airnews.net>, "Alan M. Evans" <loo...@airmail.net> writes
>Klaus Hartnegg wrote:
>
>> Q: How can I use the heap?
>> A: Memory on the heap can only be accessed with pointers.
>> Try this example, then adapt the principle to your programs:
>> type
>> arr = array [1..30000] of longint; { this is your data }
>> arrptr = ^arr; { that's a pointer to the data }
>> var
>> data : arrptr; { this is such a pointer variable }
>> begin
>> if memavail < sizeof(arr) then halt;
*only* works is your are using a 32 bit compiler. As X-Posted to c.l.p.b
I assume that your are using TP/BP product - neither work in 32 bit mode
& segements are limited to 64K.
Gerfried Cebrat
Hallo,
wo gibt's bitte die 32bit Pascal Compiler (lagernd), die Arrays größer
64kByte beherrschen.
danke
Gerfried
Klaus Hartnegg <hart...@sun2.ruf.uni-freiburg.de> schrieb im Beitrag
<5oqugl$d...@n.ruf.uni-freiburg.de>...
Pedt Scragg
In article <01bc8244$5f3c36e0$3211...@Gerfried.aon.at>, Gerfried Cebrat
<g.ce...@aon.at> writes
>Hallo,
>
>wo gibt's bitte die 32bit Pascal Compiler (lagernd), die Arrays größer
>64kByte beherrschen.
>
>danke
>Gerfried
>
Q: What about other Pascal compilers?
A: Check FPK-Pascal and GNU-Pascal.
Both are free 32-bit Pascal compilers available for DOS
that are more or less Borland compatible.
If you want a Pascal compiler for Linux or OS/2, the two same
compilers
are available for these operating systems too plus a few more, see
http://www.brain.uni-freiburg.de/~klaus/pascal/web-list.html
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Alan M. Evans
Kim Robert Blix wrote:
> Then I tested this:
> ---------------------------------------------------
> Unit Test1;
> Interface
> Var array1: Array[0..65535] of byte;
> Implementation
> End.
> ---------------------------------------------------
> Unit Test2;
> Interface
> Var array2: Array[0..65535] of byte;
> Implementation
> End.
> ---------------------------------------------------
> Program Testit;
> Uses Test1,Test2;
> Var Counter : Word;
> Begin
>
> End.
> ---------------------------------------------------
>
> Ok.. This compiles nicely.. and so it does if you use one of the
> arrays..
Try:
Program ReallyTestIt;
Uses Test1, Test2;
Begin
Array1[1] := 1;
Array2[1] := 1;
End.
If you don't use a variable, it gets stripped by the smart linker.
In any case, I got "Structure too large" when compiling the units. I
know how to get around this, but decided that changing the range of the
arrays to 0..40000 would still prove the point. Result: "Error 49: Data
segment too large."
[Disclaimer: We're talking about Turbo/Borland Pascal here. None of this
thread seems to apply to the snazzy new 32-bit compilers.]
AME
Sundial Services
In article <529BF075F5903687.789AFBB2...@library-proxy.airnews.net> "Alan M. Evans" <loo...@airmail.net> writes:
>In any case, I got "Structure too large" when compiling the units. I
>know how to get around this, but decided that changing the range of the
>arrays to 0..40000 would still prove the point. Result: "Error 49: Data
>segment too large."
>[Disclaimer: We're talking about Turbo/Borland Pascal here. None of this
>thread seems to apply to the snazzy new 32-bit compilers.]
What I do to deal with all of this, quite simply, is to use a Delphi class
with an array-style "read" and "write" method. The source-code that I write
becomes the same as if the object in question really was an array. What
actually happens is up to me.
Many programmers weaned on Visual Basic assume that VB's arrays are somehow
exempt -- that they have "solved" the problem. But in fact what the VB
interpreter does (and does not allow you to change) is essentially what you
are doing here -- 'cept you can change it. A data-structure other than a flat
contiguous block of memory *is* being used.
Kim Robert Blix
>>Pardon my french, but that us bull.
>>
>BP & TP have *one* data segment that is limited to 64K at max. If you
>want more variables you *do* need to use the heap, in TP/BP.
>
I tested it, and I where wrong.
Kim Robert Blix
mrc...@primenet.com (Mike Copeland) once said:
>> Ok.. This compiles nicely.. and so it does if you use one of the arrays.. As
>> soon as you try to poke something into the 65536'th byte though, you get a "data
>> segment too large" error.. I fold. I was pretty sure it was possible, but I
>> havent used this way of "memory allocation" in ages. hehe..
>
> This test of yours, while it may _compile_, isn't at all valid - none
>of the Var declarations in the Units is linked into the program, since
>there are no _references_ to any of the data. Apparently you don't
>understand the concept of the Data Segment, Unit vars, scoping, or how
>the Smart Linker works - and all you've done here is compile a "dummy"
>program which has no data whatsoever. So your point is moot.
I suggest you read my statement again. Read the whole thing this time. That it
will (hopefully) become obvious to you that I ofcourse tried to USE the data
aswell. Read it again please.
Antoine Leca
Martin Harvey wrote:
>
> mrc...@primenet.com (Mike Copeland) wrote:
> >> I don't know of any technical reason why the app can't declare more
> >> than one data segment..... enlighten me.
>
> >implemented the data aspect of their Pascal systems. I believe it's so
> >the optimize data referencing by loading once and maintaining the
> >contents of a hardware register throughout the duration of the program's
> >execution.
I believe speedness was a technical argument these days ;-)
> Quite likely. If I remember the segment registers on the 8086 are
> CS,DS,SS,ES. It seems to me that a sensible
> register allocation strategy would keep DS and SS constant for the
> data and stack segments, and then only change CS on far calls to allow
> for more than 64K of code, and use ES as the segment register for
> dereferencing pointers.
Furthermore, it is the natural path of evolution since the days
the target was the 8080/Z80 (which hadn't segments registers and
only one "segment" of 64K for both code, data, stack and heap).
The use of ES comes with the need to access at the same time the
data and the stack and the heap (introducing the 8086 compiler in
~82). The use of CS changes for far calls comes with the new
memory model of TP4 (large instead of compact, in C terms) in 87;
before that, CS remained constant for the duration of the program.
Antoine
Walter Schwartz
Pedt Scragg wrote:
>
> In article <90E7F85540F75B10.B0AEDBBBD1A3FD2F.7959322B0E941539@library-
> >Klaus Hartnegg wrote:
> >
> >> Q: How can I use the heap?
> >> A: Memory on the heap can only be accessed with pointers.
> >> Try this example, then adapt the principle to your programs:
> >> type
> >> arr = array [1..30000] of longint; { this is your data }
> >> arrptr = ^arr; { that's a pointer to the data }
> >> var
> >> data : arrptr; { this is such a pointer variable }
> >> begin
> >> if memavail < sizeof(arr) then halt;
>
> I assume that your are using TP/BP product - neither work in 32 bit mode
> & segements are limited to 64K.
Not true--I was writing a program in some old 16-bit Borland Turbo
Pascal
for Windows, and I came across this problem when I was using several 64k
long arrays of characters (I was trying to process text files that did
not
necessarilly have any carraige returns in them. There's got to be a
better
way to do this, but I couldn't find anything in the help file. Can
someone
tell me please), and I was able to avoid this error message by that
method.
I am absolutely sure that my compiler was 16 bit.