T.R | Title | User | Personal Name | Date | Lines |
---|
2750.1 | It's reversed... | FRAMBO::BALZER | Christian Balzer DTN:785-1029 | Mon Jul 24 1989 05:36 | 16 |
|
Yeah, that's because you probably use version 1.01 or such of A68K.
In this version the keywords CHIP and FAST are mixed up.
Use
SECTION name, DATA, FAST
to get stuff into CHIP mem. Reverse is true for FAST mem.
Wierd, isn't it? :-)
This service message with the help of my fellow brewer and assembler
guru of the Software Brewery, Heiko Rath.
Regards,
<CB>
|
2750.2 | One more... | FRAMBO::BALZER | Christian Balzer DTN:785-1029 | Mon Jul 24 1989 09:37 | 10 |
|
Uh, and I forgot to mention not to believe everything in an Abacus
book. You should expect at least on serious bug per chapter.
If you ever want to upgrade to a commercial assembler, check out
C.A.P.E. from Innovatronics.
It's written by the author of A68K and in it's newest release a
quite powerful tool.
<CB>
|
2750.3 | | FORTY2::TATHAM | Nick Tatham @REO | Tue Jul 25 1989 04:01 | 6 |
|
Thanks for the advice. Actually we're using A68K version 2.42. We tried the
FAST keyword instead and it still didn't work. There must be more to it
than that.
Nick
|
2750.4 | Oops, Asm68K not A68K... | FROCKY::BALZER | Christian Balzer DTN:785-1029 | Tue Jul 25 1989 07:34 | 12 |
| Re: *
Blush...
I'm sorry, but I goofed up here...
I was talking about Asm68K and not A68K. Heiko will try to compile
a program using A68K and see what happens...
I'll keep you informed...
Yours very confused, ;-)
<CB>
|
2750.5 | Try Asm68K | FROCKY::BALZER | Christian Balzer DTN:785-1029 | Tue Jul 25 1989 09:53 | 12 |
| Re: .4
As promised Heiko tried to compile a program with A68K. Unfortunately
his efforts have not been rewarded with success by now, since A68K
appears to miss out on some keywords and features some bugs. ;-)
If you're willing to live with the minor bug mentioned in .1, try
Asm68K on Fish #81. Works for us... :-)
Regards,
<CB>
|
2750.6 | dynamically allocate chip mem? | AIAG::WISNER | you may ask yourself 'How do I work this?'. | Wed Jul 26 1989 13:42 | 10 |
| You could always do it the way us C programmers have to:
-call the AllocMem function to allocate a block of chip memory.
-copy your data to chip memory.
It uses twice as much memory but it's a sure fire way to get your
program working.
|
2750.7 | New ways for Lattice C | TLE::RMEYERS | Randy Meyers | Wed Jul 26 1989 14:04 | 15 |
| Re: .6
> You could always do it the way us C programmers have to:
>
> -call the AllocMem function to allocate a block of chip memory.
> -copy your data to chip memory.
Naw. We C programmers (at least Lattice V5 C programmers) use the
new __chip keyword to control our storage layout.
In days gone by, (Lattice V3.10 and Lattice V4) I use to use the
"put the initialized data segment into chip memory" feature of
the compiler.
Of course, the old AllocMem and copy method works as well.
|
2750.8 | | ELWOOD::PETERS | | Wed Jul 26 1989 14:08 | 11 |
|
re .6
You shouldn't lump all C programmers together. Lattic V5 and
above has a CHIP modifier for variables. This forces the variable
to be loaded into CHIP memory.
I did do it the other way until V5.
Steve
|
2750.9 | | BAGELS::BRANNON | Dave Brannon | Wed Jul 26 1989 17:25 | 6 |
|
how about using fixhunk to force the program to use chip memory?
A gross hack but hey it even works for programs written in C :-)
-Dave
|