Hi, wanted to thank all of you for your rapid and excellent help!
Compiling with --nogcse made everything work, with a 5% (if not more)
codesize increase, which put me right up to full. Reading the docs and
using #pragma to turn it off for my (pretty long) main() solved it with
little codesize
see below, please.
regards,
Richard Erlacher
- Original Message -
From: "Dave McGuire" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, September 09, 2008 10:54 PM
Subject: Re: [Sdcc-user] documentation & open source generally
> On Sep 10, 2008, at 12:39 AM, Richard Erlacher wrote:
>> Yes, the
On Sep 10, 2008, at 12:39 AM, Richard Erlacher wrote:
> Yes, the key word there is "BIG", and I bought some of 'em back in
> the'80's.
> They were mostly rubbish ... hangar queens that were down more than
> they
> were useable.
Hangar queens...love that term. :-) I'm sure lots of high-end
Dave,
Yes, the key word there is "BIG", and I bought some of 'em back in the'80's.
They were mostly rubbish ... hangar queens that were down more than they
were useable.
The software was released to be run under UNIX only so "they" (the vendors,
who developed uner UNIX ) could easily apply pat
On Wed, Sep 10, 2008 at 9:39 AM, Dave McGuire <[EMAIL PROTECTED]> wrote:
> Umm...Most of the "big" hardware tools started out in the UNIX
> world. All the EDA software, FPGA design software, simulation
> software, etc etc...all got their start in the UNIX world, and many
> of them aren't even av
On Sep 9, 2008, at 5:53 PM, Richard Erlacher wrote:
> I'm primarily a hardware developer, though none of that can be of
> much use
> without firmware and software. The hardware tools for LINUX are
> improving
> steadily, but they've long been established under Windows, so most
> of us
> lear
Jean-Paul,
Actually, there's been a fully-programmable not-really-a-version-of-EMACS
(SlickEdit) for MS-DOS for about two decades, at least well before Windows
v3.x.At one time it was the editor of choice for large files, since most
DOS-based editors didn't handle large files very well.
I
Hello,
it looks like you still have to discover Emacs and its frames, and
Makefile.
However, don't try it under Windoze, it looks ugly !
Jean-Paul
On Mon, 08 Sep 2008 17:17:40 +0200, Richard Erlacher <[EMAIL PROTECTED]>
wrote:
> See below, please.
>
> regards,
>
> Richard Erlacher
>
>
Forwarded message follows:
Marteen,
I just ran across the multiple file info in the SDCC
user's manual, which explained the
linking of multiple files. I now seem to be able to use
more than 256 bytes of XDATA in
my program--I set up for 1024 bytes of XRAM.
I'll test the XRAM more rigorously
Jesse,
It might also help to spread your functions over
multiple source files. Every source file generates one
object file and all allocations in a segment (e.g. DSEG
which gets the slocs) are placed by the linker in one
chunk. The only way to subdivide the chunk into smaller
ones is to split
I've never tried it, it looks promising and it can't hurt to try. This
approach may be use less code than adding another function call.
--Mark
Bobby Garner wrote:
> 'Spill loactions' is mentioned one time in the manual:
> "3.2.8 Optimization Options
> --nogcse Will not do global subexpression
'Spill loactions' is mentioned one time in the manual:
"3.2.8 Optimization Options
--nogcse Will not do global subexpression elimination, this option may
be used when the compiler creates
undesirably large stack/data spaces to store compiler temporaries (spill
locations, sloc). A warning
message
You probably have a build up of spill locations. Look in the .map file
for your project for any variables with 'sloc' in the name.
You will get spill locations any time you have too many active variables
in a routine. In my experience, the best way to deal with them is to
make simpler subrout
Hi - I'm using the large data model, and as I understand it all globals
are in external RAM. And isn't idata the precious first 256 bytes, why
would I want to put an array there?
I must be missing something.
Since I'm using the large data model, the unsigned 32-bit divide routine
should be us
Try to move some global variables to external RAM if possible.
Or maybe locating few arrays in idata.
--
Ori Idan
On Tue, Sep 9, 2008 at 1:02 PM, Jesse Lackey <[EMAIL PROTECTED]>wrote:
> Hello all, until today I've been happily developing a sizable project
> with the TI CC2430 with SDCC.
>
> S
Hello all, until today I've been happily developing a sizable project
with the TI CC2430 with SDCC.
Suddenly I have a problem I don't understand. A linker error:
"?ASlink-Error-Could not get 30 consecutive bytes in internal RAM for
area DSEG"
I'm guessing it has something to do with stack space
16 matches
Mail list logo
