lib_os

Nicolas Boulay nicolas.boulay at gmail.com
Mon Dec 7 09:34:49 UTC 2009


After discussion with Xavier, it's even more complexe than that.

I forgot 16 32 64 bits choices. I haven't see how this work now. This
is part of the target.

Xavier spoke also about external optimisation. It's a way to describe
what kind of optimisation could be done on the cpu : AMD/intel or with
some support of ASM, etc... To activate or not those optimisation is
out of this scope, but we still need a means to describe what is the
target.

Nicolas

2009/12/6 Nicolas Boulay <nicolas.boulay at gmail.com>:
> Hello,
>
> I try to clean all the mess in lib_os. My goal is to be as portable as
> possible, to use advanced linux stuff for IO, to ease the port of new
> architecture  and to remove FS_MIN.
>
> Firstly, i notice sub architecture, that composed our architecture
> (Linux, Dos, Windows) :
> - c89 basic stuff that is important for small embedded device
> - posix stuff for FS_MIN (and other unices) that could be used almost
> everywhere (maybe it's not enough under DOS)
> - x86 for code use inside the DOS architecture
>
> Linux architecture will derive from posix (2008 version) who derived
> it self from c89.
>
> Todays, architecture are set by changing path directory: system.li is
> redefine in dos, windows and unix directory.
>
> But if linux derived from posix, i can't defined 2 prototypes with the
> same name.
>
> SYSTEM must be SYSTEM_LINUX under linux (SYSTEM_LINUX derive from
> SYSTEM_POSIX), but SYSTEM_POSIX must be SYSTEM if the target is posix.
> SYSTEM could inherit dynamically to the good prototype, but how to
> transmit the information from .lip to the .li code ?
>
> One of the possiblity, will be to set a global variable inside the
> compiler to set the target. An other is to defined variable in the
> .lip that is "readable" by the .li code this enable the use of a kind
> of a generic #define.
>
> Have you a better ideas ? I prefer avoiding to change the compiler code.
>
> Regards,
> Nicolas
>



More information about the Lisaac-devel mailing list