Fixed String Length

[AMSDOS]

While I was coding some Text Handling routines in Hisoft Pascal, I noticed all the hype regarding it's Fixed String Length. Strings aren't supported in Hisoft Pascal, so an array has to be defined (type CHAR) & the Length has to match the Length of the String - it cannot be larger than it (obviously), though if it's smaller, that is also a problem.
I started a discussion on another forum about Fixed String Lengths, which appears to have turned into an argument.
A couple of suggestions I got out of it was do a check for zero byte or, work out the length of an string. As it turns out I had something like that already in assembly:

Code Select Expand


org &4000


ld l,(ix+00)
ld h,(ix+01)
ld a,(hl)
ld (lenstr),a
inc hl
ld e,(hl)
inc hl
ld d,(hl)
ld (addrstr),de
ret


.lenstr defb 0
.addrstr defw 0



So when I call that with some text, the text gets stored below HIMEM. addrstr has that address along with the length of it in lenstr.


With the zero byte check, it was felt it would be slightly slower to be checking if 0 is the byte, certainly if the string was long, obtaining the string length sounds better, even though someone was arguing for something which the compiler does at compile time which has all the strings worked out. I just didn't see this happening on an Amstrad Compiler.


But what I was wondering about, with the routine above, would it be possible to allocate a certain area of memory (up to 80 Characters)? I can reserve some memory for that, the easiest approach to stick a loop at the end or I guess a LDI(R) would do the trick?

[FloppySoftware]

As you may know, C language uses the zero byte system at the end of strings.

It's easy to write functions or procedures for that system, but it has some drawbacks: low speed on long strings, and no checkings on overflows.

But it's a good solution if is used with care (and I think every program has to be written with care).

I think the solution proposed by you is used in some languages (Mallard Basic?), but it has some drawbacks too: it's more difficult to implement and manage, and may need of a garbage collector.

I would go for the first option, because it would be easy to write the support procedures to manage it (strlen, strcpy, etc), and no runtime changes are needed.

[AMSDOS]

Yeah because even when I have the Length of the String, the problem is where the Contents of the String goes & HIMEM is simply being pushed back further and I have no means of pointing where I want the string to be.

[andycadley]

If your strings are mutable, then you'd need some way a re-allocating them regardless of whether you go for C-style zero terminated or Pascal style lengths. Personally I'd go for an immutable approach where changing the content of a string is done by re-allocating it, that's usually easiest from a memory management point of view and that's probably easiest if you store the length of the string with it. I'd have thought it would be reasonably simple to write a few simple functions to handle it, though it's been years since I wrote any Pascal (and never on an 8bit system).

[FloppySoftware]

Well, I think there are two approaches when you define the strings in Pascal if you want them from 0 to 255 chars. in lenght for example (sorry, I don't kown Pascal):

Code Select Expand


   defb 0   ; Lenght
   defs 255 ; Contents (upto 255 chars. lenght)


or

Code Select Expand


   defs 256 ; Contents ends with a zero byte (255 chars. lenght max. + zero byte)


[AMSDOS]

If your strings are mutable, then you'd need some way a re-allocating them regardless of whether you go for C-style zero terminated or Pascal style lengths. Personally I'd go for an immutable approach where changing the content of a string is done by re-allocating it, that's usually easiest from a memory management point of view and that's probably easiest if you store the length of the string with it. I'd have thought it would be reasonably simple to write a few simple functions to handle it, though it's been years since I wrote any Pascal (and never on an 8bit system).

Seems to depend on which Pascal being used for the Amstrad. In Turbo Pascal 3 under CP/M, you can define a string type, have a variable point to that type & as long as the 'Text String' falls inside the size of the String Array, everything works out just fine just as I have put it in this screenshot:


[attachimg=1]


Hisoft Pascal presents more challenges, I can create a Type, string types aren't supported, so the Type is defined as an Character Array, though I need to specify a constant size for the array, because I'm defining it like that I'm bound to that size & needs to match the size specified through that Defined Type, just has I have done in this program:

Code Select Expand



   10 PROGRAM Texto;
   20
   30 TYPE st100 = ARRAY[1..11] OF char;
   40
   50 VAR txt : st100;
   60
   70 PROCEDURE display(txt : st100);
   80 BEGIN
   90  write(txt);
  100 END;
  110
  120 BEGIN
  130  display('Hello World');
  140 END.
  150



So in that example 'Hello World' occupies 1.11 for that array, though if I had defined my Type Array with the size 1..12, an error will occur.

Well, I think there are two approaches when you define the strings in Pascal if you want them from 0 to 255 chars. in lenght for example (sorry, I don't kown Pascal):

Code Select Expand


   defb 0   ; Lenght
   defs 255 ; Contents (upto 255 chars. lenght)


or

Code Select Expand


   defs 256 ; Contents ends with a zero byte (255 chars. lenght max. + zero byte)


Either one of those would be desirable. I can show you what happens, when I start passing strings to that Assembly routine.


[attachimg=2]


So I passed 3 various sized strings:

Code Select Expand

a$="text":call &4000,@a$
a$="text 2":call &4000,@a$
a$="and some more text":call &4000,@a$


but I don't know how to direct it, so the text can go to the area I defined, and if you're wondering why there's a gap between my text and where the system does it's thing, I initially had text there, but in the wrong order, so I deleted it & then I called it again going the other way just to show that using that approach the Text will eventually just fill up Memory, corrupting my program. What I've found is those Strings are managed though HIMEM, so in BASIC if I do MEMORY &8FFF for example, my text will begin at &8FFF and move back down in memory (anything above &9000 is protected).
HIMEM can be manipulated in Assembly, but there doesn't appear to be any Firmware CALLs for it & the address it resides at varies between 464 & 6128. Working out where I need it would involve where I want it in memory & adding the length of the string, just to get it into the right spot.