Article View: gnu.gcc.help
Article #46460Re: Embedded 68k cross compiler help?
From: John E. Clark
Date: Wed, 16 Nov 1994 19:53
Date: Wed, 16 Nov 1994 19:53
46 lines
3016 bytes
3016 bytes
In article <1994Nov8.084318.2613@caren.demon.co.uk> loris@caren.demon.co.uk (Loris Caren) writes: + +I reckon the real culprit is Dennis Richie (or do I mean Brian +Kernighan?) who shoveled both the system call stuff (man section 2) and +the stdio layer (section 3) into a single large libc. With hindsight it +would have been neater to separate out a libSysCall which would +have been small and system specific. I got a lot of mileage out of using a 'libc' like set of C sources that I got off a DECUS tape a million years ago. But in general there are 3 issues for 'embedded' programing. 1) How to get the initial 'stack' and C function call set up. 2) How to get 'a.out' primitive sectioning to work in a complex ROM/RAM+IO_PAGE environment. 3) How to get useful 'libc.a' functions. The answer to 1 for me has been to write the breifest bit of assembly code to set of a ram stack CPU registers and jump to the C code. The answer to 2 is 'run out of ram always'. (An alternative which I use to do for 8080/5 and Z-80 CPU's was to do a little more assemble work and have the 'data' section in ROM, but copy it to a RAM location on start up, maintaining TEXT at the ROM address space. But with certain 16/32/64 bit processors and a 'only 8 bit' data path to the ROM(hardware assembles the 8 bits into the required word size of the CPU in hestion), the running out of ROM option proves expensive and so running out of RAM is prefered anyway. As for 3, either getting source as I did for a subset of libc.a functions, or just writing some 'primitive' in(), out(c) functions has been the only general options available. Also in embedded programs the quesiton of 'reentrancy' becomes problematic for 'just ripped out of BSD libc.a or equivalent'. And anything that isn't absolutely reentrant, ie uses some semaphore scheme has potential for deadly embrace failures. (There is the common TEXT different DATA areas for a solution, but this requires indepentent 'modules' or the ability to collect program sections in way so as to produce the more complex DATA segmentation). If the embedded system has some time slicing, then the issues of common library routines, re-entrancy, and inexplicable system failures becomes even greater.
Technical Details
Message-ID:
<3ado00$p4n@news.cerf.net>Path:
arc1-ca.pugleaf.net!nntp.gmd.de!newsserver.jvnc.net!howland.reston.ans.net!usc!news.cerf.net!nic.cerf.net!synergyReferences:
<39jjd2$ho2@Mars.mcs.com> <1994Nov8.084318.2613@caren.demon.co.uk>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 11318c,5ee68be18822a181 X-Google-Attributes: gid11318c,public X-Google-Thread: 1025b4,5ee68be18822a181 X-Google-Attributes: gid1025b4,public X-Google-ArrivalTime: 1994-11-16 14:12:16 PST Path: arc1-ca.pugleaf.net!nntp.gmd.de!newsserver.jvnc.net!howland.reston.ans.net!usc!news.cerf.net!nic.cerf.net!synergy From: synergy@nic.cerf.net (John E. Clark) Newsgroups: gnu.gcc.help,gnu.misc.discuss Subject: Re: Embedded 68k cross compiler help? Date: 16 Nov 1994 19:53:36 GMT Organization: CERFnet Dial n' CERF Customer Lines: 47 Message-ID: <3ado00$p4n@news.cerf.net> References: <39jjd2$ho2@Mars.mcs.com> <1994Nov8.084318.2613@caren.demon.co.uk> NNTP-Posting-Host: nic.cerf.net