darcy@druid.uucp (D'Arcy J.M. Cain) (05/28/90)
In article <90052709560067@masnet.uucp> simon.ewins@f664.n250.z1.fidonet.org (simon ewins) writes: >Given an IBM-PC architecture to work with and limited to a SMALL memory model (for sake of argument) (I realize that using a large memory model takes the problem away!). The following does not work: > >char huge *files; >int i; > >files=(char huge *)farmalloc(2000L*82L); > >for (i=0; i<2000; i++) I think you mean "for (i=0; i<(2000*82); i+=82)" > strcpy(&files[i],"Some kind of character string"); > >for (i=0; i<2000; i++) ditto for this > puts(&files[i]); > > >All I really want to do is find a way to use a small memory model to access >an array of 2000 strings of 81 bytes in length! You have to in effect write your own functions. For example, the strcpy above can be written as: #define strcpy(dest, src) {char *s = src, *d = dest; while (*s) *d++ = *s++;} Of course you would use a name like hstrcpy or something so as not to interfere with strcpy and you have to watch for side effects but you probably get the idea. You can also write it inline if it doesn't happen in too many places. >All I can see is that in the small memory model one may be able to allocatexi >data arrays that are bigger than the memory model but the functions that one >is likely to use to access them are all mapped to NEAR pointers and throw up >when given pointer arguments longer than 16 bits. This is true?? Of course. That's why they call it small model. > >As I said, my real-world solution was to use a large memory model. However, >I still feel that somehow one must be able to use the small model (which >executes much faster due to the smaller code pointers). Anyone who can get >the above code to work in a small environment would be thought of quite >highly if they could share their success with me! Thanks... > think that something like the above is about the best you can expect. That is the trade-off between using different memory models. -- D'Arcy J.M. Cain (darcy@druid) | Government: D'Arcy Cain Consulting | Organized crime with an attitude West Hill, Ontario, Canada | (416) 281-6094 |
darcy@druid.uucp (D'Arcy J.M. Cain) (05/29/90)
In article <1990May28.000424.20473@druid.uucp> darcy@druid.UUCP (D'Arcy J.M. Cain) (Me) writes: >In article <90052709560067@masnet.uucp> >simon.ewins@f664.n250.z1.fidonet.org (simon ewins) writes: >>All I really want to do is find a way to use a small memory model to access >>an array of 2000 strings of 81 bytes in length! >You have to in effect write your own functions. For example, the strcpy above >can be written as: >#define strcpy(dest, src) {char *s = src, *d = dest; while (*s) *d++ = *s++;} >Of course you would use a name like hstrcpy or something so as not to interfere >with strcpy and you have to watch for side effects but you probably get the >idea. You can also write it inline if it doesn't happen in too many places. Some sent me e-mail pointing out 2 problems with this macro. There is no return value and it doesn't copy the null byte. I don't see the first as a real problem since as I go on to explain that it shouldn't be called strcpy then it doesn't have to act exactly like it. The second is a problem. It is easily fixed by changing to a do ... while loop. (do *d++ = *s while (*s++)). However he went on to suggest that I really should have used: char *strcpy(dest, src) char *dest, *src; { char *s = src; while (*d++ = *s++) ; return src; } Which doesn't work because it ignores the fact that the arguments may be different sized pointers. Of course it is really easy to criticize code from someone else and as soon as I realized what was wrong with that code I realized that it applied to my code as well. So I'll try again: #define mixstrcpy(d, s) { int k = 0; do d[k] = s[k]; while (s[k++]);} At that point it is probably just as easy to put it inline any way. I tested the above on Unix but it should work on brain dead OS's as well. -- D'Arcy J.M. Cain (darcy@druid) | Government: D'Arcy Cain Consulting | Organized crime with an attitude West Hill, Ontario, Canada | (416) 281-6094 |
e89hse@rigel.efd.lth.se (05/29/90)
In article <1990May28.000424.20473@druid.uucp>, darcy@druid.uucp (D'Arcy J.M. Cain) writes: >In article <90052709560067@masnet.uucp> >simon.ewins@f664.n250.z1.fidonet.org (simon ewins) writes: >>Given an IBM-PC architecture to work with and limited to a SMALL memory model (for sake of argument) (I realize that using a large memory model takes the problem away!). The following does not work: >> >>char huge *files; >>int i; >> >>files=(char huge *)farmalloc(2000L*82L); >> >>for (i=0; i<2000; i++) >I think you mean "for (i=0; i<(2000*82); i+=82)" >> strcpy(&files[i],"Some kind of character string"); >> >>for (i=0; i<2000; i++) >ditto for this >> puts(&files[i]); >> >> >>All I really want to do is find a way to use a small memory model to access >>an array of 2000 strings of 81 bytes in length! >You have to in effect write your own functions. For example, the strcpy above >can be written as: >#define strcpy(dest, src) {char *s = src, *d = dest; while (*s) *d++ = *s++;} Either you had a bad day programing this or you're really lost: 1) An int has the range -32768 <= n <= 32767, and 82*2000 is obviously not <= 32767 if you're using a 16-bit processor. (Ok we can argue a whole lot about that but I guess it's true for this the ase here.) 2) The idea with small memory model is that you use less than 64k of data, otherwise you're probably better off using big model rather than try to fix it, unless you're desperate for performance. 3) If you really want to minimise the memory usage why do you have a fixed array? (Many lines are probably less than 81 characters long.) An array with ptr to ptr or something would probably be more compact. Mixing memory models isn't easy. If you know what you're doing you'll have a hard time doing it, otherwise you'll just waste a lot of time. Henrik Sandell