gad@tellab5.tellabs.CHI.IL.US (Greg Deuerling) (09/18/89)
Has any one out there used a program called UNHUNK posted by Eric Black a
few years ago ? I've been trying to use UNHUNK & LATTICE 5.0 to write
romable code for a 68000 project I have been working on. My test program is
a very simple one, but I get errors from UNHUNK when I try to use it.
test.c :
void main()
{
int *x;
x = (int *)0x60021;
*x = 0x0f;
}
I compile with "lc -L test.c", and I use UNHUNK as "unhunk -p test test.out".
UNHUNK generates the following :
Hunk 0, type CODE, size 2412
Hunk 1, type CODE, size 40
Data Hunk size 63 doesn't match header (217)
Hunk 2, type DATA, size 252
Assigning hunk load addresses:
Hunk 0 (CODE) load address 0x0
Hunk 1 (CODE) load address 0x96C
Hunk 2 (DATA) load address 0x994
Section Origin Size(bytes)
CODE 0x0 2452 (0x994)
DATA 0x994 252 (0xFC)
BSS 0xA90 0 (0x0)
Done
1 errors encountered
Why is the output so long, I would think that test.c would be less than
100 bytes (I compiled the same test.c with UNI-WARE on a VAX and the output
was around 45 bytes).
Am I compiling wrong ??? Should I be linking differently ???
I'm somewhat a beginner at all of this, so if there is a better way to
use LATTICE to produce romable code let me know.
Are there any books or manuals sold that would give me the information
to write a program that would strip out all of the scatter loading
stuff ???
Any help any one can give me would be greatly appreciated. Thanks ......
gad.........mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (09/19/89)
In article <1602@tellab5.tellabs.CHI.IL.US> gad@tellab5.UUCP (Greg Deuerling) writes:
<I compile with "lc -L test.c", and I use UNHUNK as "unhunk -p test test.out".
<UNHUNK generates the following :
<
[deleted]
<1 errors encountered
Lattice has extended the hunk types, and convinced CBM to make them
part of the standard for the Amiga (at least, that's the way I hear
it). UnHunk predates all of this, and so doesn't understand the new
types.
One option would be to call Lattice to get the new hunk definitions,
and add them to UnHunk. You might also try compiling with -Lt instead
of -L, to force one code hunk & one data hunk.
<Why is the output so long, I would think that test.c would be less than
<100 bytes (I compiled the same test.c with UNI-WARE on a VAX and the output
<was around 45 bytes).
Because Lattice is providing lots of support software you probably
don't want in this case (but generally do): argument parsing, memory
cleanup, opening a window for stdio to point to, and other stuff.
Renaming main as _main will take care of most of it. You can also link
with the apropriate magic option to make references to __main resolve
to _main - check the library documentation, under tinymain (or is it
_tinymain?).
<Are there any books or manuals sold that would give me the information
<to write a program that would strip out all of the scatter loading
<stuff ???
I'm not sure what you mean by "strip out the scatterloading stuff."
You might look at the Lattice manuals for blink & lc; they tell you
how to get things down to a single hunk.
<mike
--
Here's a song about absolutely nothing. Mike Meyer
It's not about me, not about anyone else, mwm@berkeley.edu
Not about love, not about being young. ucbvax!mwm
Not about anything else, either. mwm@ucbjade.BITNETphil@ingr.com (Phil Johnson) (09/19/89)
In article <1602@tellab5.tellabs.CHI.IL.US> gad@tellab5.UUCP (Greg Deuerling) writes: >Has any one out there used a program called UNHUNK posted by Eric Black a >few years ago ? I've been trying to use UNHUNK & LATTICE 5.0 to write >romable code for a 68000 project I have been working on. My test program is This would NOT be a problem if Lattice would provide the Amiga user with the same tools they provide to the MSDOS community. I have ask for an Amiga- based C cross compiler like their little BLUE one, but to no avail. Come to think of it WHY hasn't SAS Institute ported their SAS product to the Amiga? A better solution (in that I use the Lattice 5.x compiler) would be to support ROMable code generation from the compiler. -- Philip E. Johnson UUCP: usenet!ingr!b3!sys_7a!phil MY words, VOICE: (205) 772-2497 MY opinion!
walker@sas.UUCP (Doug Walker) (09/28/89)
>I compile with "lc -L test.c", and I use UNHUNK as "unhunk -p test test.out". >UNHUNK generates the following : ... >Data Hunk size 63 doesn't match header (217) > >Why is the output so long, I would think that test.c would be less than >100 bytes (I compiled the same test.c with UNI-WARE on a VAX and the output >was around 45 bytes). You are linking with the Lattice-supplied startup code (c.o), which is linking in everything you need to do stdio calls, opening dos.library, defining externs and everything else. You need to get rid of the -L on the command line and issue the BLINK command yourself without the startup. The reason unhunk gets the error is that apparently it doesn't support suppressed BSS data. BLink is combining the data and BSS hunks into a single data hunk, but not putting actual data in for the BSS (since it is initialized to 0 anyway). If you get rid of c.o, it will reduce your code size to the order you expect. BLink will also not combine the hunks, solving your other problem. You need to be aware that you are responsible for opening dos.library, and you can't use ANY function calls except those in the standard amiga libraries - exec, dos, whatever else you open. This means NO PRINTF, NO MALLOC, NO FGETS. --Doug
walker@sas.UUCP (Doug Walker) (10/02/89)
In article <6437@ingr.com> phil@ingr.UUCP (Phil Johnson) writes: >This would NOT be a problem if Lattice would provide the Amiga user with >the same tools they provide to the MSDOS community. What tools are you referring to, and why are they necessary to produce ROMable code? >Come to >think of it WHY hasn't SAS Institute ported their SAS product to the Amiga? If you are interested in seeing the SAS system on the Amiga, call SAS Institute marketing and request it. Obviously the Institute is not going to port 2 million lines of code without being convinced there is a substantial market for the product. > >A better solution (in that I use the Lattice 5.x compiler) would be to support >ROMable code generation from the compiler. > The code produced by the compiler is perfectly ROMable, but you simply can't use the Amiga startup code (c.o and _main.c). You'll need to provide your own code for opening whatever AmigaDOS libraries you need (i.e. dos.library, intuition.library, etc) or, if not on AmigaDOS, for getting access to whatever system resources you need. And stdio calls are death. --Doug
phil@ingr.com (Phil Johnson) (10/03/89)
In article <1259@sas.UUCP> walker@sas.UUCP (Doug Walker) writes: >What tools are you referring to, and why are they necessary to produce ROMable >code? I am talking about cross-compilers et al. > >>Come to >If you are interested in seeing the SAS system on the Amiga, call SAS Institute >marketing and request it. Obviously the Institute is not going to port 2 >million lines of code without being convinced there is a substantial market >for the product. Doug; I called SAS about two years ago and ask if they were considering the port. I was told that there was no reason to port the SAS product to an Amiga class machine. When I asked the gentleman what he meant, he replied "The Amiga is a nice game machine, but not business quality." If it were not for the quality of John's compiler I would never do business with any business unit of the SAS institute. [When I mentioned the above conversation to Jay Denebem, I was told that it was probably some suit that just picked up the phone. Still seems to reflect a strange attitude] >> >The code produced by the compiler is perfectly ROMable, but you simply can't >use the Amiga startup code (c.o and _main.c). You'll need to provide your >own code for opening whatever AmigaDOS libraries you need (i.e. dos.library, >intuition.library, etc) or, if not on AmigaDOS, for getting access to whatever >system resources you need. And stdio calls are death. > >--Doug Thanks for the pointers. I have tried to use the 5.0 compiler once before to write code for an MC68010-based embedded control system, but could not get everything coordinated. I have a fairly large macro library that I was converting to C, but the code generated just wasn't right. I didn't use the Amiga startup code, but maybe I screwed up my libraries. Another problem could be in the linking process. Any suggestions. The Amiga makes one hell of a development platform. I built a Write Control Store that connects to my 1000 expansion port to serve as my download RAM/ROM. I use emacs in one window to create/edit assembler code and run the Quelo 68K cross-assembler to generate the executable. I use a VT100 emulator in a second window to connect to the development module. I can then move assembled code to WCS and runs the control system. If I find a problem I activated the edit/ assembler window and fix the problem the reload the WCS and do it again. It's even easier and faster than the VAXs or workstations at work. It seems that a hugh market for the Amiga is going untapped. -- Philip E. Johnson UUCP: usenet!ingr!b3!sys_7a!phil MY words, VOICE: (205) 772-2497 MY opinion!
walker@sas.UUCP (Doug Walker) (10/16/89)
In article <6713@ingr.com> phil@ingr.UUCP (Phil Johnson) writes: >Doug; I called SAS about two years ago and ask if they were considering the >port. I was told that there was no reason to port the SAS product to an Amiga >class machine. When I asked the gentleman what he meant, he replied "The >Amiga is a nice game machine, but not business quality." If it were not for >the quality of John's compiler I would never do business with any business >unit of the SAS institute. [When I mentioned the above conversation to >Jay Denebem, I was told that it was probably some suit that just picked up the >phone. Still seems to reflect a strange attitude] Two years ago hardly anyone had heard of the Amiga, and fewer had seen one. Even today, the stigma of a game machine lingers. However, if enough people called and requested an Amiga port, marketing could not ignore the interest. There is already sufficient interest in the technical area to get it done, but we can't do it without enough end-user interest; and the ONLY way we have to determine if there's end-user interest is via requests from end- users. Unfortunately, these requests must come through marketing, which is (obviously) not the most competant group to evaluate a machine's possibilites. >converting to C, but the code generated just wasn't right. I didn't use the >Amiga startup code, but maybe I screwed up my libraries. Another problem >could be in the linking process. Any suggestions. You can't modify any extern or static data; check your library for that. If you try, you're trying to modify the ROM. This pretty much rules out using malloc/free for memory management, at least if it adheres to the full UNIX spec, since all memory must be returned on exit and this requires a global. Similar problems exist with many other library routines. Best thing to do is to avoid using library routines. Since this is not entirely practical, when you do use them, BLINK your object modules with the MAP option and look at what externs are getting pulled in. --Doug