The Sinclair QL Forum

I have always assumed that the (positive) address returned from an ALCHP heap allocation would be an even address but (on QPC2 at least) I seem to be wrong. The statement is a simple:

LET decomp = ALCHP(fileLength)

print decomp MOD 2 returns 1, and the address is where I would expect it to be. Not too significant, except that my routine then uses POKE_W to set up a table of values, so POKE_W decomp,32 fails with 'invalid parameter'

Have I been making an incorrect assumption all these years?

No - it should return an even address (same as RESPR)...

Dilwyn,

ALCHP returning an odd address is pretty much impossible

ALCHP needs to return memory preceded by a standard QDOS heap header that contains a number of LONG-sized entries. If the memory returned would be on an odd address the heap header itself would be a s well, leading to all possible havoc.

There is a number of quirks in QDOS regarding address alignment (like the possibility to SEXEC a file with an odd data space size, which will never run properly), but ALCHP returning non-aligned memory areas would be a new one (to me)....

Tobias

Thanks Rich and Tobias. Seems to confirm I was right to expect it to be an even address.

Looks like either something is getting corrupted or an exponent value quirk.

The process is multiple allocations of different size, each deallocated in between (might cause fragmentation, but I'll accept that until I think of a better way). It goes wrong on QPC2 but I haven't got another computer setup yet to test on another system.

Somewhere in the chain of allocations an odd value address is returned. The last digit of the value is odd and PRINT address MOD 2 (QPC2 allows long word MOD) returns 1. There are no calculations involved, it's a simple set of ALCHP in a loop. Listing slightly simplified, but nothing important. There is a test before 1010 for size <=0.

1000 for a=1 to number_of_files
1010 size = FLEN(\filename$)
1020 IF size > 0 THEN
1030 base=alchp(size)
1040 if base <= 0 then print'Error' : stop
1050 if (base mod 2)=1 then print'Odd address':stop
1060 rem process file here
1070 rechp base
1080 end if
1090 end for a

Line 1040 sometimes gets triggered seemingly at random and I have no idea why.

I'll leave it until the weekend and apply a fresh mind to it. It's the only thing holding up the release of Q-Dock now!

Just a thought - does it happen when size is an odd number (might be able to get around it that way).

I assume that it is not the limitations of MOD causing a display error - try comparing with
(base/2) =int(base/2)

instead

If you are only loading and processing one file at a time, you would of course be better keeping track of the biggest file size so far, and only doing an ALCHP if the next file is bigger than that (and re-using the memory otherwise).

Otherwise you could quickly get an FLEN of all the files, and add them together, so you only do one big ALCHP allocation and then use an offset to the start of each file's location in memory....

RWAP wrote:Just a thought - does it happen when size is an odd number (might be able to get around it that way).

I assume that it is not the limitations of MOD causing a display error - try comparing with
(base/2) =int(base/2)
instead

If you are only loading and processing one file at a time, you would of course be better keeping track of the biggest file size so far, and only doing an ALCHP if the next file is bigger than that (and re-using the memory otherwise).

Otherwise you could quickly get an FLEN of all the files, and add them together, so you only do one big ALCHP allocation and then use an offset to the start of each file's location in memory....

Line 1050 was the one I meant, sorry.
The limitation is that the size of the next file depends on what's in the previous file, so running through to get the maximum size is not feasible, although tracking largest so far file size and only reallocating when a larger area is needed might be an option.

Need to do more testing, in case something in the file processing is causing a corruption somewhere (e.g. writing outside the allocated area) leading to corruptions and possible crashes later.

Too tired to do too much more with it tonight!

Yes just a thought - it might be an idea to check for odd file lengths and if necessary add 1 byte to them... Just wondering if ALCHP rounds up / down to get an even number of bytes (it should round up, unless there is a bug in SMSQ/e) - if it rounds down, then you would get corruption if the file is an odd number of bytes..

RWAP wrote:Just wondering if ALCHP rounds up / down to get an even number of bytes (it should round up, unless there is a bug in SMSQ/e) - .

Rich,

ALCHP should actually round up to lengths of multiples of 8 bytes according to the documents.

Tobias