Replacing Borland's startup code (c0.asm)
Shaun Jackman
compiler (BC++ 4.52, although I'm only using C, not C++) as my development
system. It's working quite well for me, except Borland's startup code
(c0.asm) makes all sorts of assumptions about memory layout and the
existence of a MS-DOS and BIOS, which obviously don't exist on my embedded
system. I've replaced the startup code with my own, and this seems to work
great (I've tried a variety of library calls and had no problems), except
malloc() always returns 0. Clearly, I have to initialize the heap some how
and tell malloc() where it can allocate the memory, but I can't find any
documentation on this and Borland was of absolutely no help.
Has anybody here tackled this same problem, or have any information on
Borland's c0.asm or malloc() implementation?
Thanks in advance,
Shaun Jackman
Thad Smith
>
> I'm targetting an embedded 186 system (AMD's AM186ED) and using Borland's
> compiler (BC++ 4.52, although I'm only using C, not C++) as my development
> system. It's working quite well for me, except Borland's startup code
> (c0.asm) makes all sorts of assumptions about memory layout and the
> existence of a MS-DOS and BIOS, which obviously don't exist on my embedded
> system. I've replaced the startup code with my own, and this seems to work
> great (I've tried a variety of library calls and had no problems), except
> malloc() always returns 0. Clearly, I have to initialize the heap some how
> and tell malloc() where it can allocate the memory, but I can't find any
> documentation on this and Borland was of absolutely no help.
I don't have that version, but earlier pro versions of the compiler came
with source for the run-time library. Do you have a CRTL directory
(that's the run time source library directory for BC++ 3.1)? If so,
look for the source to the startup code and malloc().
Thad
Robert Scott
<sha...@gray-interfaces.com> wrote:
>I'm targetting an embedded 186 system (AMD's AM186ED) and using Borland's
>compiler (BC++ 4.52, although I'm only using C, not C++) as my development
>system. It's working quite well for me, except Borland's startup code
>(c0.asm) makes all sorts of assumptions about memory layout and the
>existence of a MS-DOS and BIOS, which obviously don't exist on my embedded
>system. I've replaced the startup code with my own, and this seems to work
>great (I've tried a variety of library calls and had no problems), except
>malloc() always returns 0. Clearly, I have to initialize the heap some how
>and tell malloc() where it can allocate the memory, but I can't find any
>documentation on this and Borland was of absolutely no help.
>Has anybody here tackled this same problem, or have any information on
>Borland's c0.asm or malloc() implementation?
Don't bother to try to make Borland's malloc() happy. Just write
your own. If you have a problem with writing MyMalloc() everywhere
in your code where you would have written malloc(), then use a header
file that is included in all your code that says
#define malloc MyMalloc
One possible problem would be if you call any Borland RTL routines
that themselves call malloc - but I don't know if there are
any such animals.
Or, use the librarian to replace Borland's malloc in the library
with your own version and call it malloc. That should make
everybody happy.
Robert Scott
Ann Arbor, Michigan (rscott {at sign} wwnet {period} net is my real email address.)
(My automatic return address is intentionally invalid to foil spammers.)
Eric
If so, I would be glad to hear from you, since I'm in the latest stages
of the developement of a linker/locator software that allows to use Delphi
to create embedded applications and I'm now searching for beta-testers.
The product is functionnal, and already was used in the developement of
a commercial product (http://rad-control.com/app/brochure-tw20.pdf).
It actually targets Intel 80C188EA,EB & EC controllers, but AMD devices
support is considered.
the classic "Hello world" demo (writting to a standard LCD display) with
Pascal source, ASM listing, Rommable object code and schematic diagram
can be downloaded from here :
ftp://rad-control.com/hello.zip
Full code including startup, vector table & constant init, and the demo
itself is under 1 Ko ROM space and RAM usage is minimal too (512 bytes
stack, 96 bytes for partial vector table, 6 bytes for data).
If you are interrested, feel free to contact me at in...@rad-control.com
regards,
Eric.
-------------------------------------------------------
Shaun Jackman wrote:
> I'm targetting an embedded 186 system (AMD's AM186ED) and using Borland's
> compiler (BC++ 4.52, although I'm only using C, not C++) as my development
> system. It's working quite well for me, except Borland's startup code
> (c0.asm) makes all sorts of assumptions about memory layout and the
> existence of a MS-DOS and BIOS, which obviously don't exist on my embedded
> system. I've replaced the startup code with my own, and this seems to work
> great (I've tried a variety of library calls and had no problems), except
> malloc() always returns 0. Clearly, I have to initialize the heap some how
> and tell malloc() where it can allocate the memory, but I can't find any
> documentation on this and Borland was of absolutely no help.
> Has anybody here tackled this same problem, or have any information on
> Borland's c0.asm or malloc() implementation?
>
Arie de Muynck
AFAIK it is enough to call your own function malloc(): this will override
(replace on linking time) the library function.
Regards,
Arie de Muynck
---
arie at ademu dot com
Arie de Muynck
AFAIK it is enough to call your own function malloc(): this will override
(replace on linking time) the library function. Also works for the Borland
library functions using malloc().
Marius Randak
> On Tue, 9 May 2000 14:03:09 -0600, "Shaun Jackman"
> <sha...@gray-interfaces.com> wrote:
>
> >I'm targetting an embedded 186 system (AMD's AM186ED) and using Borland's
> >compiler (BC++ 4.52, although I'm only using C, not C++) as my development
> >system. It's working quite well for me, except Borland's startup code
> >(c0.asm) makes all sorts of assumptions about memory layout and the
> >existence of a MS-DOS and BIOS, which obviously don't exist on my embedded
> >system. I've replaced the startup code with my own, and this seems to work
> >great (I've tried a variety of library calls and had no problems), except
> >malloc() always returns 0. Clearly, I have to initialize the heap some how
> >and tell malloc() where it can allocate the memory, but I can't find any
> >documentation on this and Borland was of absolutely no help.
> >Has anybody here tackled this same problem, or have any information on
> >Borland's c0.asm or malloc() implementation?
>
> Don't bother to try to make Borland's malloc() happy. Just write
> your own.
Yes, it is the best solutions if you need dynamic memory.
If you will use only C all the job can be done without malloc if you
want C++ malloc is a must. Writing a simple malloc function is not a big
task but full featured dynamic allocation memory manager is not easy to
implement. Run a search engine looking for "dynamic memory allocation"
and "multitasking" and/or "embedded systems" to learn more. The code
provided by AMD and Intel may also help.
The standard malloc would not be used here due to poor performance, non
determinable time of execution and heap fragmentation. As I can
remember the BCC3.1 malloc uses memory from local stack if compiled in
small memory model but if other memory model is set during compilation
it is probably using DOS calls(?).
I'm using similar hardware and old good Frank Borland C v3.1 and newer
tried to run the standard malloc on my hardware.
Regards,
mr
Shaun Jackman
It's an ethernet system and all it's output is network oriented.
Cheers,
Shaun
Eric <in...@rad-control.com> wrote in message
news:39188CB8...@rad-control.com...
> Would you be interrested to use windows based Delphi 1 (16 bits version)
for the task ?
>
> If so, I would be glad to hear from you, since I'm in the latest stages
> of the developement of a linker/locator software that allows to use Delphi
> to create embedded applications and I'm now searching for beta-testers.
>
> The product is functionnal, and already was used in the developement of
> a commercial product (http://rad-control.com/app/brochure-tw20.pdf).
>
> It actually targets Intel 80C188EA,EB & EC controllers, but AMD devices
> support is considered.
>
> the classic "Hello world" demo (writting to a standard LCD display) with
> Pascal source, ASM listing, Rommable object code and schematic diagram
> can be downloaded from here :
> ftp://rad-control.com/hello.zip
> Full code including startup, vector table & constant init, and the demo
> itself is under 1 Ko ROM space and RAM usage is minimal too (512 bytes
> stack, 96 bytes for partial vector table, 6 bytes for data).
>
> If you are interrested, feel free to contact me at in...@rad-control.com
>
> regards,
>
> Eric.
>
> -------------------------------------------------------
>
> Shaun Jackman wrote:
>
> > I'm targetting an embedded 186 system (AMD's AM186ED) and using
Borland's
> > compiler (BC++ 4.52, although I'm only using C, not C++) as my
development
> > system. It's working quite well for me, except Borland's startup code
> > (c0.asm) makes all sorts of assumptions about memory layout and the
> > existence of a MS-DOS and BIOS, which obviously don't exist on my
embedded
> > system. I've replaced the startup code with my own, and this seems to
work
> > great (I've tried a variety of library calls and had no problems),
except
> > malloc() always returns 0. Clearly, I have to initialize the heap some
how
> > and tell malloc() where it can allocate the memory, but I can't find any
> > documentation on this and Borland was of absolutely no help.
> > Has anybody here tackled this same problem, or have any information on
> > Borland's c0.asm or malloc() implementation?
> >
Norm Dresner
create your own startup .OBJ and then put it first in the project. The only
other restriction was that the name had to be C0*.xOBJ where the x had to
match the memory model and the * could be anything you wanted. For example,
my Large-model AMX startup module was C0AMXL.OBJ which I created by adding
AMX's startup code into the source of C0 that came with the Borland
compiler.
I also did a similar thing with the C-thru_ROM startup module that allows
creating ROM-able and otherwise embedded programs with the Borland 3.x
compiler. This product -- which was dropped by the manufacturer (as too
successful, I think) -- was a trivial way to create embedded programs
because it came with several varieties of startup code and replacements for
the most common library routines like malloc(). I still think that this was
one of the finest investments my company made (AMX was the other, but that's
another, very long and off-topic) story.
I made a brief attempt to do the same thing in 4.x and never got it to work,
but that doesn't mean that I tried every possible combination of names and
locations.
Hope this helps.
Norm
Shaun Jackman <sha...@gray-interfaces.com> wrote in message
news:39186...@news.cadvision.com...
RMain
management functions. It is entirely possible that
Go to Embedded Systems Programming Archive at:
http://www.embedded.com/
Select the "Demos & Code" link at left.
Scroll down a bit (unless you have a 21" monitor...)
Select the "Master Code List" link.
Search for "ROM" (there are several).
If these don't cover the malloc init issue, you might want to check other
trade mags - I'm sure I saw an article on ROMing MS C programs, but I can't
locate it just now.
Good Luck,
RM.
Shaun Jackman <sha...@gray-interfaces.com> wrote in message
news:39199...@news.cadvision.com...
Michael Roch
Shaun Jackman schrieb:
>
> I'm targetting an embedded 186 system (AMD's AM186ED) and using Borland's
> compiler (BC++ 4.52, although I'm only using C, not C++) as my development
> system. It's working quite well for me, except Borland's startup code
> (c0.asm) makes all sorts of assumptions about memory layout and the
> existence of a MS-DOS and BIOS, which obviously don't exist on my embedded
> system. I've replaced the startup code with my own, and this seems to work
> great (I've tried a variety of library calls and had no problems), except
> malloc() always returns 0. Clearly, I have to initialize the heap some how
> and tell malloc() where it can allocate the memory, but I can't find any
> documentation on this and Borland was of absolutely no help.
> Has anybody here tackled this same problem, or have any information on
> Borland's c0.asm or malloc() implementation?
>
> Thanks in advance,
> Shaun Jackman
See to http://www.devtools.com . Paradigm has a complete IDE for
embedded systems based on Borland's BC++ 4.5x. This package includes the
library files for heap, remote debugging per RS232, floating point math
and all what's possible in BC++ 4.5x.
--
Michael Roch
Sagaert Johan
www.devtools.com ) complete with a am80186 based board for just 299$
--
Kind Regards
Sagaert Johan
Norm Dresner <nd...@attl.net> schreef in berichtnieuws
vAiS4.1536$XO1....@bgtnsc06-news.ops.worldnet.att.net...
> Shaun Jackman <sha...@gray-interfaces.com> wrote in message
> news:39186...@news.cadvision.com...
Robert Scott
> As I can
>remember the BCC3.1 malloc uses memory from local stack if compiled in
>small memory model....
This would be impossible in any memory model because whatever malloc
does, the memory it returns must remain assigned after a function
that called it returns. This would not be the case if malloc
allocated off the local stack. There is a function called alloca()
that allocates off the stack, but with alloca() it is understood
that the memory goes away as soon as the local stack frame is
deallocated.