derek@speedy.WISC.EDU (Derek Zahn) (08/17/87)
I am working on a simple on-line manual system. I plan to have the manual
entries reside in a set of files. When it comes time to read a manual
entry, I was planning to see how long the entry is, AllocMem that much
space, read the page in, and then FreeMem the space again when finished.
My question: will this behavior (constantly AllocMemming and FreMemming
chunks of memory) be detrimental to system performance, or will the Amiga
coalesce the memory blocks when I do each FreeMem? Thanks! Oh, when this
thing is finished I may post it; would anybody want it?
derek
Derek Zahn @ Wisconsin
USENET: ...!{allegra,heurikon,ihnp4,seismo,ucbvax}!uwvax!derek
BITNET: derek at wiscvm
ARPA INTERNET: derek@cs.wisc.edu
"It's much much much too hot in here."baer@percival.UUCP (09/01/87)
I have been working on a program that uses AllocMem(), and I can't get it
to work with 16-bit Manx C. I know it will work when I compile with 32-bit
ints. Is there a way I can make it work properly in 16-bit Manx with a
statement like the following:
SpriteHead = (struct VSprite *)AllocMem(sizeof(struct VSprite), MEMF_PUBLIC |
MEMF_CLEAR);
I'm still getting the hang of Manx (I'm still a little used to UNIX), so
forgive my ignorance.
Rob Peck, are you out there? This example is from your ReadyGels()
routine, with the if taken out. BTW I already tried:
void *AllocMem(); AND
long AllocMem();
(The second was used hastily without a lot of forethought :-)
All suggestions will be appreciated.
--
-Ken Baer.
"Press the button labeled 'Extreme Emergency' on the console" - The Doctor.
USENET - ...tektronix!reed!percival!baer OR baer@percival.pdx.com
"The Few, The Proud, The Criminally Insane - Oberlin Computer Science" - me.dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/02/87)
>SpriteHead = (struct VSprite *)AllocMem(sizeof(struct VSprite), MEMF_PUBLIC | > MEMF_CLEAR); extern void *AllocMem(); SpriteHead = AllocMem((long)sizeof(struct VSprite), MEMF_PUBLIC|MEMF_CLEAR); The size argument must be a longword. When you compile with the 16-bit Aztec C sizeof() returns a short. -Matt
higgin@cbmvax.UUCP (Paul Higginbottom SALES) (09/02/87)
in article <872@percival.UUCP>, baer@percival.UUCP (Ken Baer) says: > I have been working on a program that uses AllocMem(), and I can't get it > to work with 16-bit Manx C. ... > SpriteHead = (struct VSprite *)AllocMem(sizeof(struct VSprite), MEMF_PUBLIC | > MEMF_CLEAR); ^^^^^^ |||||| The problem is that you're not declaring (casting) the number of bytes you wish to allocate as a long integer (as AllocMem expects). Simply insert "(long)" before "sizeof". > -Ken Baer. Paul.
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (09/03/87)
In article <872@percival.UUCP> baer@percival.UUCP (Ken Baer) writes: > >I have been working on a program that uses AllocMem(), and I can't get it >to work with 16-bit Manx C. [ ... ] >SpriteHead = (struct VSprite *)AllocMem(sizeof(struct VSprite), MEMF_PUBLIC | > MEMF_CLEAR); >BTW I already tried: >void *AllocMem(); Welcome to the Wonderful World of MANX C. Do this: extern void *AllocMem(); [ ... ] SpriteHead = AllocMem ((long) sizeof (struct VSprite), MEMF_PUBLIC | MEMF_CLEAR); You have to coerce that sizeof() reference to a long or you'll get stack misalignment. Tons 'o fun. MANX Programming Rule #1: *ALL* Amiga-specific function call arguments are 32 bits wide. Make sure they are this size, or bad karma will result. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Bike shrunk by popular demand, dual ---> !{well,unicom}!ewhac O----^o But it's still the only way to fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
baer@percival.UUCP (Ken Baer) (09/04/87)
Thanks to all who replied to my question. Being that I have only been using Manx C since June, I have been discovering that there are a number of little 'tricks' you need to do to get it to be compatable with Lattice. A lot of this kind of info floats around the boards and networks, but isn't formally documented. I think it would be really neat to compile (no pun intended) all of these little tidbits together somewhere, like maybe in an Amazing Computing article [are you listening John Foust?]. I really want to start developing some real software, and I am a little frustrated with thumbing through maunuals that don't have answers to my Manx questions. Just a thought. Well, back to hacking :-). -- -Ken Baer. "Press the button labeled 'Extreme Emergency' on the console" - The Doctor. USENET - ...tektronix!reed!percival!baer OR baer@percival.pdx.com "The Few, The Proud, The Criminally Insane - Oberlin Computer Science" - me.
cheeser@dasys1.UUCP (Les Kay) (09/12/87)
Having just taken the plunge with a massive programming job on the Amiga, I find myself wondering which of the various 'C''s I should do the work under. I decided to post this message in this thread since it seems to be pointing out some difficulties in using MANX.... If YOU had to write a massive game program for the Amiga and later port it to the Atari ST and Apple //gs (forget about the gs, that'll be in assembly) what would you pick as a 'c' development system? And why? Probably reply in mail, unless others here are interested....but as this is sort of a religous question, we could end up with all sorts of flaming.... Smoke from my ears... Sparks from my eyes.... Flames from my nostrils.... (and you should see me when I get worked up!) cheeser@dasys1
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/14/87)
>Having just taken the plunge with a massive programming job on the Amiga, >I find myself wondering which of the various 'C''s I should do the work >under. I decided to post this message in this thread since it seems to >be pointing out some difficulties in using MANX.... I would suggest Aztec-C mainly because it will compile int's as either 16 bits or 32 bits (Most Atari compilers use 16 bit ints), and you don't want to have to worry about a program compilable under BOTH 16 and 32 bit ints. The difficulty wasn't Aztec-C itself, but the fact that the originator was not familar with the problems that usually crop up when one is using 16 bit integers. >If YOU had to write a massive game program for the Amiga and later port >it to the Atari ST and Apple //gs (forget about the gs, that'll be in assembly) >what would you pick as a 'c' development system? And why? I would: (A) Get reference manuals on both computers (B) Study them (C) Write the game on one machine, organizing the machine dependant stuff to make porting easier. -Matt
jesup@mizar.steinmetz (Randell Jesup) (09/15/87)
In article <8709141841.AA06918@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>Having just taken the plunge with a massive programming job on the Amiga, >>I find myself wondering which of the various 'C''s I should do the work >>under. I decided to post this message in this thread since it seems to >>be pointing out some difficulties in using MANX.... > I would suggest Aztec-C mainly because it will compile int's as either >16 bits or 32 bits (Most Atari compilers use 16 bit ints), and you don't want >to have to worry about a program compilable under BOTH 16 and 32 bit ints. Don't forget that Lattice 4.0 also handles 16-bit ints, AND it has prototypes, which can save immeasurable problems like the originator of this thread had (prototypes allow checking the types of all arguements). > (A) Get reference manuals on both computers > (B) Study them > (C) Write the game on one machine, organizing the machine dependant > stuff to make porting easier. I agree absolutely. You might even want to write a small module of routines for handling things that are different between the machines BEFORE writing any of the other code (Line-Draws, file access, requesters, open window, etc.) -- Randell Jesup (Please use one of these paths for mail) mizar!jesup@steinmetz.UUCP (uunet!steinmetz!{mizar|crd}!jesup) jesup@ge-crd.ARPA
jdow@gryphon.UUCP (09/17/87)
In article <8709141841.AA06918@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>Having just taken the plunge with a massive programming job on the Amiga, >>I find myself wondering which of the various 'C''s I should do the work >>under. I decided to post this message in this thread since it seems to >>be pointing out some difficulties in using MANX.... > > I would suggest Aztec-C mainly because it will compile int's as either >16 bits or 32 bits (Most Atari compilers use 16 bit ints), and you don't want >to have to worry about a program compilable under BOTH 16 and 32 bit ints. > So does Lattice these days. 3.10 handles 16 bit or 32 bit integers nicely. -- <@_@> BIX:jdow INTERNET:jdow@gryphon.CTS.COM UUCP:{akgua, hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!jdow Remember - A bird in the hand often leaves a sticky deposit. Perhaps it was better you left it in the bush with the other one.
dca@toylnd.UUCP (David C. Albrecht) (09/20/87)
> > I would suggest Aztec-C mainly because it will compile int's as either > >16 bits or 32 bits (Most Atari compilers use 16 bit ints), and you don't want > >to have to worry about a program compilable under BOTH 16 and 32 bit ints. > > > So does Lattice these days. 3.10 handles 16 bit or 32 bit integers nicely. Weeell, first off let me say that I use Lattice because when I was starting off I was more interested in speed of implementation than speed of result and Manx in 16 bit mode has some real negative aspects in this regard. There is a difference between saying 16 bit 'ints' and 16 bit 'shorts'. As far as I know of Lattice 3.10 doesn't support 16 bit 'ints'. In any case, when it comes to using 16 bit ints in Lattice though I have to differ, they don't handle them very nicely. Case in point: I noticed that some of the dhrystone results reported for the Amiga and the ST were reported for 16 bit ints. I decided I would see how well Lattice would perform if I went through and changed all the various 'int' declarations to 'short' and then compiled under Lattice. It made virtually no difference the results were still under 700 dhrystones unlike Manx which gives in the 900 territory. Note that I had already tried this experiment on my AT&T Unix PC which is based on a 10Mhz 68010 and a compiler that uses 32 bit ints and it went from about 1050 dhrystones to over 1300. Needless to say I was a bit disapointed by Lattice's performance. Hopefully the as yet vaporware 4.0 version will correct the situation. David Albrecht
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (09/25/87)
In article <174@toylnd.UUCP> dca@toylnd.UUCP (David C. Albrecht) writes:
<> > I would suggest Aztec-C mainly because it will compile int's as either
<> >16 bits or 32 bits (Most Atari compilers use 16 bit ints), and you don't want
<> >to have to worry about a program compilable under BOTH 16 and 32 bit ints.
<> >
<There is a difference between saying 16 bit 'ints' and 16 bit 'shorts'. As
<far as I know of Lattice 3.10 doesn't support 16 bit 'ints'.
Correct. 4.0 should have real 16-bit shorts. So we can all enjoy the
benefits of an OS that expects integers on the stack that are longer
than an 'int'.
<In any case, when it comes to using 16 bit ints in Lattice though I have
<to differ, they don't handle them very nicely.
Dig out the compiler, and start going through the output when you
declare things as shorts. You'll see lots of "EXT.W" and "EXT.L"
instructions. This follows C semantics, where all integer arithmetic
is done in the int type - or longer.
[Description of changing ints to shorts in Lattice with no gain, but
getting a benefit on the AT&T 3b1 (aka the Unix PC).]
Hmm. I wouldn't expect much of a gain in Lattice. It tends to generate
good code (more on that later, when I have the time). If the 3b1
compiler is as abysmal as most PCC's I've seen, then it might make a
lot of difference. Have you looked at the code coming out of Lattice
in both cases? And from the 3b1? Then again, the 3b1 compiler could
have the semantics wrong, and not being doing the extend to 32 bits.
Lattice 3.03 had that bug.
<mike
--
I'm gonna lasso you with my rubberband lazer, Mike Meyer
Pull you closer to me, and look right to the moon. mwm@berkeley.edu
Ride side by side when worlds collide, ucbvax!mwm
And slip into the Martian tide. mwm@ucbjade.BITNETdillon@CORY.BERKELEY.EDU (Matt Dillon) (12/01/87)
Here's a question: If I AllocMem() a block of memory, can I FreeMem() a subsegment of that block (being careful to do everything on 8 byte boundries). That is: ptr = AllocMem(16, MEMF_PUBLIC); FreeMem(ptr+8,8); so ptr now points to 8 bytes allocated memory. Then at some point later on: FreeMem(ptr, 8); ??? -Matt
haitex@pnet01.cts.com (Wade Bickel) (12/01/87)
dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > Here's a question: > > If I AllocMem() a block of memory, can I FreeMem() a subsegment of >that block (being careful to do everything on 8 byte boundries). That is: > > ptr = AllocMem(16, MEMF_PUBLIC); > FreeMem(ptr+8,8); > > so ptr now points to 8 bytes allocated memory. Then at some point > later on: > > FreeMem(ptr, 8); > > ??? > > -Matt Seems that you should be able to, though I would think that a structured approach to coding your allocations would avoid the need to do so. The syntax and logic seem good, TRY IT! Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
stever@videovax.Tek.COM (Steven E. Rice, P.E.) (12/03/87)
In article <2060@crash.cts.com>, Wade Bickel (haitex@pnet01.cts.com) writes: > dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > >> Here's a question: >> >> If I AllocMem() a block of memory, can I FreeMem() a subsegment of >> that block (being careful to do everything on 8 byte boundries). That is: >> >> ptr = AllocMem(16, MEMF_PUBLIC); >> FreeMem(ptr+8,8); >> >> so ptr now points to 8 bytes allocated memory. Then at some point >> later on: >> >> FreeMem(ptr, 8); >> >> ??? >> >> -Matt > > > Seems that you should be able to, though I would think that > a structured approach to coding your allocations would avoid the > need to do so. The syntax and logic seem good, TRY IT! Ummmmmmm. . . Perhaps it might be a good idea to find out just *how* the system keeps track of what was allocated and how it is returned! In many cases, when memory is allocated, a few extra bytes are included at the beginning, identifying the block size and leaving space for a pointer so the block can be linked back into the free memory pool. If you turn back a piece you haven't explicitly allocated, you might find that the system would use data in the unreturned part as the block size, and stomp on part of the data in the unreturned part to link the "block" into the free list. Could be very, very messy. . . Steve Rice ----------------------------------------------------------------------------- new: stever@videovax.tv.Tek.com old: {decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever inews > 50% filler inews > 50% filler inews > 50% filler inews > 50% filler inews > 50% filler inews > 50% filler inews > 50% filler inews > 50% filler inews > 50% filler inews > 50% filler
louie@trantor.umd.edu (Louis A. Mamakos) (12/06/87)
From "ROM Kernel Manual, Vol 1" (The older CBM published version) Page 1-64, "Memory Allocation" "Partial blocks can be deallocated, but note again that FreeMem() rounds your address down to the nearest even multiple of MEM_BLOCKSIZE and the size up to the nearest multiple before the FreeMem() is perfromed." Why speculate? Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming