Øyvind Harboe wrote:
On 8/11/06, Jonathan Larmour <[EMAIL PROTECTED]> wrote:
By implication from this code, you're trying to get C++ code to operate
even before the kernel is initialised, hence the hoops with self==NULL.
It's an invitation to problems. I'm extremely hesitant about trying to
claim that C++ code will work at such an early stage of initialisation.
It's hard to argue against a fear about something that you believe might
exist.
By going to the effort of getting something working, it implies it works
and we want it to work. Before the kernel is even initialised, nevermind
started, that's a very difficult position to maintain.
Even CYG_INIT_IO is after CYG_INIT_KERNEL, so I'm not clear what
initialisation you are trying to support. C++ exceptions in the HAL? I'd
surely have thought not, but if not but it's HAL code, why not just build
with -fno-exceptions.
I'm decompressing an FPGA image while programming an FPGA. There are
*many* things that can go wrong and this code is *greatly* simplified
by having exceptions.
This probably is just going to come down to a difference of opinion, but in
my view exceptions are meant to be exactly that - things that are out of
the ordinary and should not happen in the normal course of events. HAL
initialisation should either work or fail. Exceptions should not be used as
intra-program communication.
You can still use setjmp/longjmp. Although I'm aware that doesn't help if
you are relying on automatic calling of C++ destructors for stack objects.
Decompressing the FPGA must happen before CYG_INIT_IO since there is a
UART in the FPGA.
Okay.
These changes also add bloat to support something that almost no-one will
want to do, and are at best hardware specific.
Bloat? Isn't this so little as to nearly be a matter of subjective
opinion? Doesn't POSIX threads get used in system that have a little
more oomph so percentage wise this should be miniscule?
It's the thin end of the wedge. With pretty much the sole exceptions of the
BSD net stack and SNMP stack, eCos has always endeavoured to be
lightweight, including in the POSIX layer. POSIX adds a fair bit of code
(ROM space), but does not need to add much data (RAM space). Your change
adds over half a K of data to every POSIX library user. All to support one
implementation of one particularly early running driver, solely at
initialisation time, and not thereafter.
I'm sure this patch is entirely right for your code design and
implementation preferences, but I don't see it being generally applicable,
and only see it adding unnecessary space for virtually everyone. In this
case, other users may not be using POSIX threads because they want to, but
only because they are required to by the libstdc++ implementation. You
can't assume they have that oomph.
eCos is open source so you have the freedom of making changes like this. It
doesn't mean that every change needs to be contributed back for all to use,
particularly if it is highly specialised.
Anyway, I've said my bit. I suspect unfortunately we may have to agree to
disagree.
Jifl
--
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
