robinson@renoir.Berkeley.EDU (Michael Robinson) (04/24/87)
I have a program I am writing as a C/assembly hybrid for which I have need
of a 64k (2^16, 65536) byte table.
I have a program which generates the table, and can modify said program
to generate the output in any format desired.
I have the Manx 3.4 commercial package.
I would like to get the whole table loaded cleanly into the final executable
with a symbol pointing at the center so I can access all 65536 bytes using
register indirect with index addressing (small style).
I tried generating a C initialized static array, but Manx puked on it
(arrays must be < 32k bytes).
I tried generating an assembly array out of ds.b's but the assembler put in
unit separators (0x1f) between every line, broke the table into three hunks,
and the linker wouldn't recognize the public symbol in the center.
My next idea was to change the table generator program to output the table
directly into a .o format file, with the external symbol, hunk information,
and everything. Then I realized I only had documentation for the AmigaDOS
object file format, and that the Manx format was completely different.
If anyone can help me in any way, I would greatly appreciate it if you
could send me mail.
I will summarize responses to the net.
Thanks
------------------------------------------------------------------------------
"If you study the logistics and heuristics of the mystics,
You will find that their minds rarely move in a line"
Fifty percent of everything is below average.
Mike Robinson USENET: ucbvax!ernie!robinson
ARPA: robinson@ernie.berkeley.educarolyn@cbmvax.cbm.UUCP (Carolyn Scheppner CATS) (04/30/87)
In article <18567@ucbvax.BERKELEY.EDU> robinson@renoir.Berkeley.EDU (Michael Robinson) writes: >I have a program I am writing as a C/assembly hybrid for which I have need >of a 64k (2^16, 65536) byte table. > >I have a program which generates the table, and can modify said program >to generate the output in any format desired. > >I have the Manx 3.4 commercial package. > >I would like to get the whole table loaded cleanly into the final executable >with a symbol pointing at the center so I can access all 65536 bytes using >register indirect with index addressing (small style). >[] Not sure if this is appropriate, but my suggestion is to use AllocMem() to allocate the memory for the table. You can then set up whatever kind of pointer you want to point at whatever spot you want. If the created table must be saved for loading by another program, just Write() the whole thing to a file. This would only require a single Write(). The other program could use a single Read() to bring the table back into its own AllocMem()'d contiguous area. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
robinson@renoir.Berkeley.EDU (Michael Robinson) (05/05/87)
In article <1799@cbmvax.cbmvax.cbm.UUCP> carolyn@cbmvax.UUCP (Carolyn Scheppner CATS) writes: >In article <18567@ucbvax.BERKELEY.EDU> I (Michael Robinson) write: >>I have a program I am writing as a C/assembly hybrid for which I have need >>of a 64k (2^16, 65536) byte table. >> >>I would like to get the whole table loaded cleanly into the final executable >>with a symbol pointing at the center so I can access all 65536 bytes using >>register indirect with index addressing (small style). >>[] > > Not sure if this is appropriate, but my suggestion is to use AllocMem() >to allocate the memory for the table. You can then set up whatever kind >of pointer you want to point at whatever spot you want. Except for one message suggesting I get Lattice, this is the only response I received. But I managed to figure it out on my own, anyway. Because the table in question contains data that will always be needed by the program (the program will not run without it), I did not want to keep it in a separate file, and load it in at run time. To much possibility for user error. My solution was to create an assembly language program containing only 256 "dcb.b 256, 42" statements (see note below), and labels at the first and 128th block. I then assembled this program, and, after some experimentation, I was able to determine enough of the structure of the linker format that I was able to modify the program that generates the table to do fseeks into the existing .o file, and replace the 42's with the actual data. >Carolyn Scheppner -- CBM >>Amiga Technical Support<< Note below: The Manx assembler limits the size of a dcb (Define constant block) to 256 bytes, but does not check that the value you specified is equal or less than that. Consequently, you can specify a block 257 bytes long, and the assembler will merrily produce a 256 byte block without informing you that you are not getting what you asked for. If you specify a number large enough, the assembler will crash (guru). I would guess that this constitutes a bug. It is especially annoying, because the manual makes no mention of the 256 byte limit in the manual. ------------------------------------------------------------------------------ "If you study the logistics and heuristics of the mystics, You will find that their minds rarely move in a line" "The Ranger isn't going to like it, Yogi." Mike Robinson USENET: ucbvax!ernie!robinson ARPA: robinson@ernie.berkeley.edu
rokicki@rocky.UUCP (05/05/87)
robinson@renoir.Berkeley.EDU (Michael Robinson) writes: > Note below: The Manx assembler limits the size of a dcb (Define constant > block) to 256 bytes, but does not check that the value you specified is > equal or less than that. Consequently, you can specify a block 257 bytes > long, and the assembler will merrily produce a 256 byte block without > informing you that you are not getting what you asked for. If you specify a > number large enough, the assembler will crash (guru). I would guess that > this constitutes a bug. Yep, 3.40a is shore a nice package, but it does have a few minor flaws. First, the linker does not complain if you get more than 64K of data, it just wraps it around, if you use the +Q option with the small memory model. (+Q puts constant strings in the data segment.) This one took me a while to hunt down. If your program is exhibiting strange behavior, like some variables apparently not initialized to 0, you might generate a symbol table dump and check the size of your data segment. Secondly, addressing a byte array with an unsigned int still does not work. For instance, the code: getme(a,i) char *a ; unsigned i ; { return(a[i]) ; } Generates: . . . move.b (a0,d1.w),d0 . . . which interprets i (in d1) as a signed value.
ali@rocky.STANFORD.EDU (Ali Ozer) (05/06/87)
In article <288@rocky.STANFORD.EDU> Tomas Rokicki writes: >Yep, 3.40a is shore a nice package, but it does have a few minor flaws. There's one "flaw" that existed in 3.20a and that was not fixed in 3.40a. One of my roommates just bought 3.40a (I'm still waiting for my upgrade), so I of looked through his manual. And, guess what, the error that had cracked me up in 3.20a is still there! On page 25 of "Release Doc," section 8.3, there's a section about Fred Fish that goes: "Fred Fish is happy to announce that the AMIGA Freely Redistributable Software Library now contains 45 disks ... If you just can't wait, or can't find copies locally, he is willing to make these disks available for the cost of the media, mailing materials, postage, and miscellaneous expenses (like wear and tear on my drives) ..." I have this vision of Fred going over to Jim Goodnow's house to use Jim's disk drives... Cracks me up everytime I read it! Anyway, but the price of the disks and the number of disks available has been updated, so seems like this "flaw" somehow escaped detection. In any case, 3.40a looks like a wonderful package, can't wait for mine... BTW, Lee Taran and I just received personalized plates for our car --- After a three month wait. But, it was worth it --- The plates say: +------------------+ | G O A M I G A | | | | California | +------------------+ Now all we need is a Maserati to go with these plates... Anybody want to donate one? Send me email. Ali Ozer, ali@rocky.stanford.edu