murphy@newton.physics.purdue.edu (William J. Murphy) (04/07/90)
I was trying to play with a bit of code which would read from stdin and
then use the parallel.device to output what was read. I came across an APTR
and can't seem to find out what exactly is an APTR. For that matter, what's
a BPTR. I would have to assume that APTR = Amiga Pointer = 32bit pointer?
BPTR = BCPL pointer = long-word aligned pointer.
I want to read the data from stdin into a character buffer and be able to
point the APTR to the start of this buffer and use the data contained
therein to be output to the parallel.device.
I tried something like this:
APTR printbuffer;
char *address;
main()
{
address = (char *)AllocMem(256, MEMF_FAST);
if (address == NULL)
exit(99);
scanf("%s", address);
printbuffer = (APTR)address;
/* bunch of parallel.device code from RKM Libs and Devs example parallel.c
deleted to make this short.*/
ParallelIO->IOPar.io_Data = (APTR)printbuffer;
SendIO( ParallelIO );
}
I have tries this where I have made printbuffer = (APTR)"Let the printer type
this" instead of trying to assign/cast the pointer to the beginning of
the character buffer. It worked. But the above example with the cast
doesn't. I figure that I must not understand what an APTR is.
Thanks for any pointers, 8^)
--
Bill Murphy | Zaphod, Vell he's just zis
murphy@newton.physics.purdue.edu | guy you know.
Amiga, it's not a religion, it's a lifestyle |valentin@cbmvax.commodore.com (Valentin Pepelea) (04/09/90)
In article <3421@newton.physics.purdue.edu> murphy@newton.physics.purdue.edu.UUCP (William J. Murphy) writes: > >I would have to assume that APTR = Amiga Pointer = 32bit pointer? Correct. >BPTR = BCPL pointer = long-word aligned pointer. Way back when the evil language BCPL was invented, computers had no more than 64K of addressing space. The BCPL language allowed the illusion of working with a contiguous 256K by using pointers that were shifted right by two bits. Thus a pointer to address 1024 would be represented as a 256 in BCPL. >I have tries this where I have made printbuffer = (APTR)"Let the printer type >this" instead of trying to assign/cast the pointer to the beginning of >the character buffer. It worked. Try putting a printf("%s",buffer); right after the scanf() call to see whether you are obtaining what you want from scanf(). Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
daveh@cbmvax.commodore.com (Dave Haynie) (04/10/90)
In article <10712@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: >In article <3421@newton.physics.purdue.edu> murphy@newton.physics.purdue.edu.UUCP (William J. Murphy) writes: >>BPTR = BCPL pointer = long-word aligned pointer. >Way back when the evil language BCPL was invented, computers had no more than >64K of addressing space. The BCPL language allowed the illusion of working with >a contiguous 256K by using pointers that were shifted right by two bits. >Thus a pointer to address 1024 would be represented as a 256 in BCPL. Huh? BCPL was essentially designed for word-addressed machines, like the DEC-10 and DEC-20, rather than byte addressed machines, which comprise most of the rest of the world. On a DEC-20, location 0 contains one 36 bit word, location 1 contains the next 36 bit word, etc. These machines actually only had 18 bits of address space (eg, 1/2 a word), but that really didn't enter into the picture. On the 68000, as most other popular computers, location 0 contains one byte, location 1 contains the next byte, etc. In order to rectify the difference between the word vs. byte addressing, the BCPL compiler used for the original Amiga DOS subsystem mapped every longword as one memory location, from its point of view. So location 0 would be a 32 bit word, location 1 the next 32 bit word, etc. Just like the DEC machines, so the BCPL language itself looked exactly the same. Only, to actually access a reference to this logical mapping, the BCPL compiler had to produce code that took (BCPL_pointer << 2) to create a working 68000 pointer. The actual BCPL code in the Amiga's DOS subsystem has been on the way out for some time, but the BCPL pointer lingers on for interface reasons here and there. I've heard that there are alternative BCPL implementations without the evil address mappings, probably on PDP-11s or VAXen. Apparently this changes the BCPL language ever so slightly, and drastically improves the quality of the produced code. I suppose the smartest thing would be to no use BCPL in the first place. >Valentin -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
mapjilg@bath.ac.uk (J I L Gold) (04/11/90)
OK, now I know what these are, what is a CPTR ? -- # J.Gold | mapjilg@uk.ac.bath.gdr # # University of Bath , UK | jilg@uk.ac.bath.maths #
deven@rpi.edu (Deven T. Corzine) (04/12/90)
On 11 Apr 90 10:34:19 GMT, mapjilg@bath.ac.uk (J I L Gold) said: mapjilg> OK, now I know what these are, what is a CPTR ? From <exec/types.h>: -- typedef unsigned long ULONG; /* unsigned 32-bit quantity */ typedef unsigned char *STRPTR; /* string pointer */ typedef STRPTR *APTR; /* absolute memory pointer */ /* sigh. APTR was misdefined, but compatibility rules. Heres what it * should have been */ typedef ULONG CPTR; /* absolute memory pointer */ typedef unsigned char TEXT; -- So, as you can see, CPTR is a "fixed" APTR typedef. Unfortunately, it is still misdefined. Properly, APTR should be defined as: typedef VOID *APTR; /* absolute memory pointer */ which is a generic pointer. The original APTR ended up being an unsigned char **, which is clearly wrong. The "fixed" CPTR is an unsigned long, which is actually worse, since APTR is at least a pointer. (just a pointer to a pointer) CPTR is not a pointer, so if the pointers in the machine were, say, 64 bits, a CPTR would be the wrong size, but an APTR would not. All of this is somewhat academic at this point, since all three forms work within the present architecture -- they all resolve to a 4-byte (longword) value. Still, both "official" definitions are wrong. *sigh* Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
mcmahan@netcom.UUCP (Dave Mc Mahan) (04/13/90)
In article <DEVEN.90Apr12051138@netserv2.rpi.edu> deven@rpi.edu (Deven T. Corzine) writes: > > >So, as you can see, CPTR is a "fixed" APTR typedef. Unfortunately, it >is still misdefined. Properly, APTR should be defined as: > >typedef VOID *APTR; /* absolute memory pointer */ > >which is a generic pointer. The original APTR ended up being an >unsigned char **, which is clearly wrong. The "fixed" CPTR is an >unsigned long, which is actually worse, since APTR is at least a >pointer. (just a pointer to a pointer) CPTR is not a pointer, so if >the pointers in the machine were, say, 64 bits, a CPTR would be the >wrong size, but an APTR would not. > >All of this is somewhat academic at this point, since all three forms >work within the present architecture -- they all resolve to a 4-byte >(longword) value. Still, both "official" definitions are wrong. > The only problem I have run into with this is when doing pointer arithmatic. Doing things like incrementing a pointer tends to give different results, depending on if you use APTR, CPTR, or whatever. I usually just use casts to keep my compiler from barfing and then make it whatever I want it to be within the declaration of my program. >*sigh* > >Deven double sigh, -dave
deven@rpi.edu (Deven T. Corzine) (04/13/90)
On 13 Apr 90 04:41:15 GMT, mcmahan@netcom.UUCP (Dave Mc Mahan) said: Dave> The only problem I have run into with this is when doing pointer Dave> arithmatic. Doing things like incrementing a pointer tends to Dave> give different results, depending on if you use APTR, CPTR, or Dave> whatever. I usually just use casts to keep my compiler from Dave> barfing and then make it whatever I want it to be within the Dave> declaration of my program. Yes. As I believe I recall, a (void *) is supposed to increment as a (char *) would. Which is the most sensible. But yes, it's a pain. Deven> *sigh* Dave> double sigh, Agreed. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.