#68000 Assembly X-Devel.
5 messages in this thread
We are having problems with assembly cross-development (PC to 68000 ROM
system).
Currently we are using Cross Code 'C' by Software Development Systems.
Our current cross assembler and linker cannot deal with the following
assembly macros for the labels:
L_DMA_SRC0_global
L_DMA_SRC1_global
L_DMA_LEN_global
L_DMA_SRC0_global =
((VDP_DMA_SRC_M | ((global>>9)&0xFF))<<16) | (VDP_DMA_SRC_L |
((global>>1)&0xFF));
L_DMA_SRC1_global =
((VDP_AUTO_INC_SZ | (2))<<16) | (VDP_DMA_SRC_H |
((global>>17)&0xFF));
L_DMA_LEN_global =
((VDP_DMA_LEN_H | ((global_END – global)>>9))<<16) |
(VDP_DMA_LEN_L | (((global_END – global) >>1) &0xFF));
The "VDP" values are constants. The "global" values refer to addresses in
the data area to created by the assembler/linker.
The global values are forward references. Unfortunitly the linker can only
resolve direct references to these labels, not the complex expressions
above.
If anyone knows of a 68K assembly cross development system that will deal
with this sort of stuff …. let me know.
? You might want to check out Microtec Research. I don't know if they
address your specific issue, but their tools are pretty solid and flexible.
They're at (408) 980-1300 (Sunta Clara, CA)
I saw Ed's reply and thought I'd throw in my two cents. I've been using
Microtec for three years now for 68020 development and while it has gotten
the job done, I'm somewhat less than thrilled. We use both PCs and Micro
VAXs running ULTRIX (Unix) as development platforms and there are some
minor incompatabilities between the two versions. The big problems I've had
are:
1. Until the latest release, they didn't support packed record
structures. i.e. All long and short words are forced to even byte
boundaries. Of course, that's not as big a problem if your doing 68000
work, because the processor makes that requirement anyway. To be fair, I
couldn't find any other vendors that support structure packing either and
the latest Microtec release supposedly does.
2. The compiler would occaisionaly crash if asked to produce a mixed
assembly language listing, i.e. core dump in Unix.
3. The PC version tends to run out of symbol space with relatively small
programs. There is supposedly an EMS fix for this, but I've yet to see it
work. The bottom line is: make sure the compiler does what you need before
shelling out the high price they ask for it. P.S. The PR for the latest
release does look impressive, I'm even considering upgrading after two
years of saying NO THANKS.
Our applications creates 640K Bytes of ROM code. We are still fustrated by
the long build times and macro problems as previously noted. Purchasing
25MHz 386's should help.
I read your message last week and decided that I would come back to it when
I had some time to figure out what you were up to in the code example. I
have come back to it and have decided that I really don't want to know that
badly.
I have done a little research, though, and may have an answer for you.
I also do cross development for an imbedded 680×0 (68020) machine. I mix c
and assembler language, and have been known to tweak the assembler language
source output of the c compiler.
The c compiler is a product of Production Languages Corp.,
Weatherford, TX, (800)525-6289. The product has been getting better and
better and this small company deserves any success they have achieved. You
may find that you like it enough to convert to c–I have written our board
level manufacturing test package in c (most of it), and it works.
The assembler, linker, librarian is the Avocet package which was
actually the Quelo package–they bought them out, or some such thing. Call
(800)448-8500 for information. It looks as if the linker will handle the
complex expressions, operators, etc. in your example.
But…, you may want to talk to PLC before you call Avocet–they may
have a solution, and it may save you some money.