Is it OK to link libgcc.a to my OS kernel?

[cycl0ne]

Hi,

i know, but i cant link libgcc.a.. because its missing xD.

Dont know where i can get one for Windows->cygwin Cross development.

On the other hand. how big will my bin file get to this? i was proud on not leaving 16kb.

with those two things.. everything works for me.


Here is my CPU Flag for the Compiler:
-mcpu=arm1176jzf-s

[JamesM]

Hi,

i know, but i cant link libgcc.a.. because its missing xD.

Dont know where i can get one for Windows->cygwin Cross development.

On the other hand. how big will my bin file get to this? i was proud on not leaving 16kb.

with those two things.. everything works for me.


Here is my CPU Flag for the Compiler:
-mcpu=arm1176jzf-s

The 1176 is an ARMv6A core (raspberry pi, perchance?) so it won't have UDIV/SDIV. libgcc.a will come with gcc - it will be in one of the lib/ directories. find $DIR -name libgcc.a , where $DIR is where you installed your cross compiler.

[cycl0ne]

Found it, but:

1,53 MB (1.608.922 bytes)

No chance, i will stay with my two implementations.

and yes a Raspberry Pi

[Combuster]

No chance, i will stay with my two implementations.

Therefore, 1000 / 3 = 999

1,53 MB (1.608.922 bytes)

And how much of that will not be used and therefore doesn't end up in your binary?

[cycl0ne]

same as my implementation, since the second part ist from the source of libgccc

[JamesM]

Found it, but:

1,53 MB (1.608.922 bytes)

No chance, i will stay with my two implementations.

and yes a Raspberry Pi

It's a *library*. The compiler doesn't link the entirety of it in (unless you use --whole-archive).

Link it and see your codesize increase by about 100 bytes.

[Owen]

As to ARM not having native divide, if you're compiling for ARMv7A (for example ARM1176, Cortex-A8, Cortex-A9), the UDIV and SDIV instructions are available. Ensure you're using the correct -mcpu= or -march= flags in your compile line.

UDIV and SDIV are marked "RM" in the ARM instruction set reference card, which means "ARMv7-R and ARMv7-M only". This actually seems to be a simplification of the truth:

Full manual quote (ARMv7-A/R):

ARMv7 implementation requirements and options for the divide instructions
Any implementation of the ARMv7-R profile must include the SDIV and UDIV instructions in the Thumb instruction set.
Any implementation of the Virtualization Extensions must include the SDIV and UDIV instructions in the Thumb and ARM instruction sets.
In the ARMv7-R profile, the implementation of SDIV and UDIV in the ARM instruction set is optional.
In an ARMv7-A implementation that does not include the Virtualization Extensions, it is IMPLEMENTATION DEFINED whether:

• SDIV and UDIV are not implemented
• SDIV and UDIV are implemented only in the Thumb instruction set
• SDIV and UDIV are implemented in the Thumb and ARM instruction sets.

The ID_ISAR0.Divide_instrs field indicates the level of support for these instructions, see ID_ISAR0, Instruction Set Attribute Register 0, VMSA on page B4-1588 or ID_ISAR0, Instruction Set Attribute Register 0, PMSA on page B6-1829:

• a field value of 0b0001 indicates they are implemented in the Thumb instruction set
• a field value of 0b0010 indicates they are implemented in both the Thumb and ARM instruction sets.

So, processor dependent

[cycl0ne]

Found it, but:

1,53 MB (1.608.922 bytes)

No chance, i will stay with my two implementations.

and yes a Raspberry Pi

It's a *library*. The compiler doesn't link the entirety of it in (unless you use --whole-archive).

Link it and see your codesize increase by about 100 bytes.

Ok question: i read something about internal exception in lbgcca (division zero). So i think the binary will end up with more bytes including the exception handlers.

nevertheless thanks, i will try it.

At the moment im thinking about implementing USB, the raspberry pi has only USB i can acces, no ps/2. Is there any modular driver for USB EHCI in source? (Freescale? Any one tried? im not sure abouot their license). which can be "easily" adopted?

[JamesM]

So i think the binary will end up with more bytes including the exception handlers.

libgcc.a doesn't have fault handlers.

At the moment im thinking about implementing USB, the raspberry pi has only USB i can acces, no ps/2. Is there any modular driver for USB EHCI in source? (Freescale? Any one tried? im not sure abouot their license). which can be "easily" adopted?

USB is far from simple.

So, processor dependent

Yes, although I've yet to see an 7A without them. And if it doesn't have them, it has VFP so you can do floating point divide. Or even better, NEON for integer vector divide.

[cycl0ne]

USB is far from simple.

I know, thats why i was asking. I would even pay a license for a modular USB Stack, capable of Ethernet/Mass/Keyboard/Mouse. Problem is: paying a license will forbid me to put my code to public. So there is a dilema, cause i wanted to share my code to the raspberry community.
On the other hand, if i hired someone.. how much do you think he wanted for the usb stack? 500$ 1000$? 3000$ 10.000$ for his work?

I will have a look at barebox. seems they have an easy to adopt usb stack.

[JamesM]

If you're writing a hobby OS, why shy away from the hard stuff? That's the most rewarding, surely?

If you're not writing a hobby OS, use linux?

[cycl0ne]

Ok you got me, i bought a book : USB: The Universal Serial Bus and I will try to code it myself