ARM Cortex-M Microcontroller startup files

[Jens Bauer via Digitalmars-d]

On Friday, 1 May 2015 at 07:44:49 UTC, Timo Sintonen wrote:
> On Thursday, 30 April 2015 at 23:59:18 UTC, Jens Bauer wrote:
>> On Thursday, 30 April 2015 at 21:35:44 UTC, Mike wrote:
>>> On Thursday, 30 April 2015 at 21:08:22 UTC, Jens Bauer wrote:
>>>> Thus I would expect the hook to be somewhere in vfprintf ?
>>> Sometimes the toolchain vendors provide this, sometimes the 
>>> programmer has to do it.
>>
>> Uhm, in that case, why not supply a weakref dummy, eg. 
>> functions that can be overridden.
{snip}
>> -So it should be fairly easy to change newlib 'requirements' 
>> to 'optional'. :)
>>
>> I feel like trying this out, perhaps when the new light comes. 
>> ;)
>
> Please do not make yet another c compiler. Make a D compiler.
> File system support can be an option that can be selected. A 
> file in D is an object. Try to think object oriented way.

That would do nicely, but I was merely thinking about crippling 
the library so it does 'nothing'.

If we were simply to supply 'fopen' instead of 'open', returning 
an object would be fairly straightforward.

A hacky open could return a pointer to an object, because the 
returned value is a 32-bit integer, which is the same size as a 
pointer and:
     "If successful, open() returns a non-negative integer, termed 
a file
     descriptor.  It returns -1 on failure, and sets errno to 
indicate the error."

-That means though, that the RAM *must* be in the area 0x00000000 
... 0x7fffffff in order to satisfy the "non-negative integer" 
statement.

But it's of course not "pretty", and it would not be portable to 
a 64-bit system, if open does not return a 64-bit integer on 
those systems.

We could also keep returning a 'file number', then have a 
function, which found the FILE* (which is an object) for this 
'file number'. This would most likely limit the number of files 
one can keep open simultaneously. The limit could be changed 
during startup.

The problem with these two implementations is that I don't use 
files in microcontrollers, so there will be cases where it's 
insufficient. But being able to open more than 1000 files 
simultaneously does not make much sense on a microcontroller, 
which has 64K RAM or less.

If anyone has a better suggestion, I'm ears all over the place.. 
I mean I'm all ears. ;)