🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.gcc.help
Article #46460

Re: Embedded 68k cross compiler help?

#46460
From: John E. Clark
Date: Wed, 16 Nov 1994 19:53
46 lines
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!synergy
References: <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