RE: bdi2000

RE: bdi2000

[Rod Boyce]

I would say from what you have just described you have not set the DER
register correctly.  Instead of just breaking on actual break points you are
breaking on all interrupts.

Our DER register line is set to:

WSPR	149	0x2002000F	; DER : set debug enable register


Regards,
Rod

 -----Original Message-----
From: 	Muaddi, Cecilia [mailto:cecilia.muaddi@alloptic.com]
Sent:	Tuesday, 28 January 2003 2:06 p.m.
To:	'linuxppc-embedded@lists.linuxppc.org'
Subject:	bdi2000


Hello,

I am having some difficulty setting up to work with the abatron bdi2000.  Is
there a mailing list somewhere I can post questions?

Since I am here,  can someone tell me what have I configured incorrectly on
the bdi2000.

I followed the document "Using the Abatro BDI2000 to Debug a Linux Kernel",
and for some reason,
without setting any breakpoint, the bdi2000 always seem to break somehwere
after the print on the console:

Dentry-cache hash table entries: 1024 (order: 1, 8192 bytes)
Inode-cache hash table entries: 512 (order: 0, 4096 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 2048 (order: 1, 8192 bytes)
POSIX conformance testing by UNIFIX



When I do an "info" in the bdi telnet window, this is what I got
- TARGET: target has entered debug mode
BDI>info
    Target state      : debug mode
    Debug entry cause : system call
    Current PC        : 0xc0005ebc

Without the BDI2000, the kernel comes up without a problem.

Thanks

Cecilia


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

C++ Library recommendations ...

[jgdon]

Hello,

I have currently have some applications running with glibc/ulibc ...

For porting purposes I would find it noce if there were some nice and
small C++ libs supporting basic STL features (sets, vectors, lists) and
things like iosstreams ...

Anyone have any rocommendations ...

I believe last time I checked most C++ libs are rather large ??

Any advice would be great ...

Jim

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

C++ Library recommendations ...

[Jim Don]

Hello,

I have currently have some applications running with glibc/ulibc ...

For porting purposes I would find it nice if there were some nice and
small C++ libs supporting basic STL features (sets, vectors, lists) and
things like iosstreams ...

Anyone have any recommendations ...

I believe last time I checked most C++ libs are rather large ??

Any advice would be great ... thanks ...

Jim


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: C++ Library recommendations ...

[Jaap-Jan Boor]

Jim,

I just use libstd++ coming with gnu g++, it's not too big (shared ~300k)
compared to glibc (shared ~1.2 M)

when linking statically, the linker normally only takes what you need,
so this will be less.

Jaap-Jan

>
> Hello,
>
> I have currently have some applications running with glibc/ulibc ...
>
> For porting purposes I would find it nice if there were some nice and
> small C++ libs supporting basic STL features (sets, vectors, lists) and
> things like iosstreams ...
>
> Anyone have any recommendations ...
>
> I believe last time I checked most C++ libs are rather large ??
>
> Any advice would be great ... thanks ...
>
> Jim
>
>
>

---
J.G.J. Boor
Lucent Technologies Nederland b.v.	Room:  BE-525
Optical Networking Group TMS Data 	Phone: +31 (0)35 687 4721
Larenseweg 50, P.O. Box 1168, 		Fax:   +31 (0)35 687 5976
1200 BD, Hilversum, The Netherlands	mailto:jjboor@lucent.com


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: C++ Library recommendations ...

[Felix Domke]

Jaap-Jan Boor wrote:
> I just use libstd++ coming with gnu g++, it's not too big (shared ~300k)
> compared to glibc (shared ~1.2 M)

problem is that the STL is a template library, so a lot of code is
produced when using these tamplates.

i highly recommend to use normal lists and cast pointers (like in good
old C times) again, even with the need of allocating two chunks per list
item (pointer and data itself).
Using STL makes your application MUCH bigger, and, often slower.
STL is optimized for huge data structures, but for most things
memcpy'ing (and using for example an array/vector) is much faster than
using a list or hash, which has optimal - for example linear or even log
- complexity. The thing the STL guy forgot is to keep in mind than
1000*linear (list insertions... ) is still worse than 1*exp (memcpy when
doing vector insertions... but take this only as an example) when your
list has, for example, 5 entries.

and most of the lists are NOT accessed ten thousand times, do NOT have
one million entries where 1000*linear is a LOT more than 1*exp complexity.

just my 2 cent...

felix


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: C++ Library recommendations ...

[Roland Dreier]

    Felix> The thing the STL guy forgot is to keep in mind than
    Felix> 1000*linear (list insertions... ) is still worse than 1*exp
    Felix> (memcpy when doing vector insertions... but take this only
    Felix> as an example) when your list has, for example, 5 entries.

This isn't really on topic for the linuxppc list, but anyway...

What you say isn't really true.  The STL is generally quite efficient,
and provides both vector<> and list<> data structures (in addition to
slist<> and deque<>).

In fact, since a good implementation of vector<> will double the size
of its memory allocation each time it needs to grow it, the cost of
adding elements to the vector<> is still linear when amortized.

Best,
  Roland

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/