From: bc@freeuk.com
On 30/10/2025 05:11, Waldek Hebisch wrote:
> bart wrote:
>>
>> Because existing solutions DIDN'T EXIST in a practical form (remember I
>> worked with 8-bit computers), or they were hopelessly slow and
>> complicated on restricted hardware.
>>
>> I don't need a linker, I don't need a makefile, I don't need lists of
>> dependencies between modules, I don't need independent compilation, I
>> don't use object files.
>>
>> The generated makefile for the 49-module CDECL project is 2000 lines of
>> gobbledygook; that's not really selling it to me!
>>
>> If *I* had a 49-module C project, the build info I'd supply you would
>> basically be that list of files, plus the source files.
>
> I sometime work with 8-bit microcontrollers. More frequently I work
> with 32-bit microcontrollers of size comparable to 8-bit
> microcontrollers. One target has 4 kB RAM (plus 16 kB flash for
> storing programs). On such targets I care about program size.
> I found it convenient during developement to run programs from
> RAM, so ideally program + data should fit in 4 kB. And frequently
> it fits. I have separate modules. For example, usually before
> doing anything else I need to configure the clock. Needed clock
> speed depends on program. I could use a general clock setting
> routine that can set "any" clock speed. But such routine would
> be more complicated and consequently bigger than a more specialized
> one. So I have a few versions so that each version sets a single
> clock speed and is doing only what is necessary for this speed.
> Microcontrollers contain several built-in devices, they need
> drivers. But it is almost impossible to use all devices and
> given program usually uses only a few devices. So in programs
> I just include what is needed.
>
> My developement process is work in progress, there are some
> things which I would like to improve. But I need to organize
> things, for which I use files. There are compiler options,
> paths to tools and libraries. In other words, there is
> essential info outside C files. I use Makefile-s to record
> this info. It is quite likely that in the future I will
> have a tool to create specialized C code from higher level
> information. In such case my dependecies will get more
> complex.
>
> Modern microcontrollers are quite fast compared to their
> typical tasks, so most of the time speed of code is not
> critical. But I write interrupt handlers and typically
> interrupt handler should be as fast as possible, so speed
> matters here. And as I wrote size of compiled code is
> important. So compiler that quickly generates slow and big
> code is of limited use to me. Given that files are usually
> rather small I find gcc speed reasonable (during developement
> I usually do not need to wait for compilation, it is fast
> enough).
>
> Certainly better compiler is possible. But given need to
> generate reasonably good code for several differen CPU-s
> (there are a few major familes and within family there are
> variations affecting generated code) this is big task.
>
> One could have better language than C. But currenly it
> seems that I will be able to get features that I want by
> generating code. Of course, if you look at whole toolchain
> and developement process this is much more complicated than
> specialized compiler for specialized language. But creating
> whole environment with features that I want is a big task.
> By using gcc I reduce amount of work that _I_ need to do.
> I wrote several pieces of code that are available in existing
> libraries (because I wanted to have smaller specialized
> version), so I probably do more work than typical developer.
> But life is finite so one need to choose what is worth
> (re)doing as opposed to reusing existing code.
>
> BTW: Using usual recipes, frequently gives much bigger programs,
> for example program blinking a LED (embedded equivelent of
> "Hello world") may take 20-30 kB (with my approach it is
> 552 bytes, most of which is essentially forced by MCU
> architecure).
>
> So, gcc and make _I_ find useful. For microcontroller
> projects I currently do not need 'configure' and related
> machinery, but do not exlude that in the future.
>
> Note that while I am developing programs, my focus is on
> providing a library and developement process. That is
> potential user is supposed to write code which should
> integrate with code that I wrote. So I either need
> some amalgamation at source level or linking. ATM linking
> works better. So I need linking, in the sense that if
> I were forbiden to use linking, I would have to develop
> some replacement and that could be substantial work and
> inconvenience, for example textual amalgamation would
> increase build time from rather satisfactory now to
> probably noticable delay.
>
My background is unusual. I started off in hardware, and developed a
small language and tools to help with my job as test and development
engineer, something done on the side.
Those tools evolved, and I got used to creating my own solutions, ones
that were very productive compared to the (expensive and slow) compilers
that were available then.
Linking existed, in the form of a 'loader' program that combined
multiple object files into one executable; a trivial task IMO, but other
people's linkers seemed to make a big deal of it (they still do!).
I didn't use makefiles: I had a crude IDE which used a project file,
listing my source modules. So the IDE already knew all the which files
needed to be submitted for compilation, on the occasions I needed to
compile everything.
I was also familiar enough with my projects to know when I only need to
recompile the one module. In any case, compilation was quite fast even
on the early 80s home and business computers I used (and used to help
design!).
I only use linking now for my C compiler, but that task is done within
my assembler; there are no object files.
My main language uses a whole-program compiler so linking is not
relevant. External libraries are accessed dynamically only.
When I wrote commercial apps, where users wanted to add their own
content, I provided a scripting language for that. Developing add-ons
was done within the running application.
Now, if someone wanted to statically link native code from my compiler
into their program, or vice versa, I can generate object files in
standard format.
Then a normal linker is used, but *they* are using the linker; not me!
There are other solutions too: others can create libraries that are then
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
