Linux-Development-Sys Digest #714, Volume #7     Wed, 29 Mar 00 05:13:11 EST

Contents:
  Re: BIOS support (Robert Redelmeier)
  Re: Precision of Linux's libm??? (Tom Mitchell)
  Re: Advice on PowerPC MPC823 Dev. Tools? (Graham Stoney)
  libpcap in so format? ("Marc E. Christensen")
  How do I make shared libraries? ("Marc E. Christensen")
  Re: Windows CE target for GCC? (Christopher Browne)
  Re: How do I make shared libraries? ("Arthur H. Gold")
  Recomendation for a graphical 'diff' style program for Linux? (Tim Harvey)
  Re: Recomendation for a graphical 'diff' style program for Linux? (Kaz Kylheku)
  Re: UART overrun errors (Mats Byggmastar)
  Re: BIOS support (H. Peter Anvin)
  Re: Advice on PowerPC MPC823 Dev. Tools? ("David Brown")
  Re: How do I make shared libraries? (Andreas Kahari)
  Re: Zero padding in sprintf() doesn't work for strings - HELP ! (Wolfram Gloger)
  Re: Recomendation for a graphical 'diff' style program for Linux? (Eugene Morozov)

----------------------------------------------------------------------------

From: Robert Redelmeier <[EMAIL PROTECTED]>
Subject: Re: BIOS support
Date: Tue, 28 Mar 2000 19:33:03 -0800

Mark Langsdorf wrote:
>     How much of the BIOS does Linux require to load the kernel
> image, then?  Just enough to get the GP-BUS and SDRAM set up,
> or something more?  If one were trying to to write a pared down
> BIOS to boot Linux, could the VGA or floppy drive controller be
> left off?

Loading the kernel is the easy part.  Just load the MBR (LILO boot.s)
at 0x00007C00 and jump there.  BIOS has _alot_ of work to do before
it can get there.

First, the BIOS must test the hardware, and size RAM.  Then it
must program the Northbridge and southbridge (load config registers,
mostly from CMOS, but some from the SDRAM SPD ROM).  There alot
of PIC, PIT, DMA, etc chips virtualized that must be setup correctly.
Then it can find and run all the adapters (cards) initialization 
routines.

This is all extremely board & chipset specific.  If you don't do it,
the PCI bus will probably be dead, and I doubt Linux will be able
to bring it to life.  Some BIOSes have a protected boot block for
failed flashes.  An ISA VGA card will work, but that's it.  I do 
wish the OpenBIOS folks luck. 

If you're intersted, the original IBM PC, XT & AT BIOSes were
published (with comments).  Don't know about PS/2.  They will
give you a good idea about what needs to be done, but things have
gotten more complicated with programmable VLSI ASIC's for 
bus interfacing.   

-- Robert

------------------------------

From: Tom Mitchell <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Precision of Linux's libm???
Date: Tue, 28 Mar 2000 19:01:19 -0800
Reply-To: [EMAIL PROTECTED]


On Thu, 17 Feb 2000, Johan Kullstam wrote:
> From: Johan Kullstam <[EMAIL PROTECTED]>
> Subject: Re: Precision of Linux's libm???
> 
> chad <[EMAIL PROTECTED]> writes:
> 
> > I am looking into doing so molecular modeling on Linux platforms because
> > they are cost effective.  After running some tests, I find errors,
> > albeit small, in the results as compared to similar tests on SGIs or
> > SUNs.
> 
> most CPUs use IEEE 64 bit floating point (or 32 bit sometimes).  intel
> uses 80 bit floating point registers.
....
yes, internal registers....
....
> some of your calculation procedes with 64 and some with 80 bit
> precision.  if your algorithm is reasonably well-behaved in 64 bits,
> it should work just fine.

Caution the intel 80 bit registers are data+exponent.  The
precision is not 80 bits (64 bits, sign?). The same number
as and external 64 bit float has 52(sign?) bits...
  http://developer.intel.com/design/intarch/manuals/27216403.pdf

For newer Pentium some folks are using the SIMD/MMX
instructions... in library functions.  Watch out for
functions like sin() and sqrt() that are sometimes hardware
instructions sometimes library functions.

And the new IA64 has 82 bit internal floating point regs with 64
bits of significand. http://developer.intel.com/vtune/cbts/ia64/index.htm

> > I have heard about this in the past when talking to some
> > professors but I never thought much about it until now.  Knowing that
> > errors propagate and grow (especially after weeks of computation),

Weeks!!!... you do need to get this right ;-)

> well designed algorithms minimize this growth.

yep.

> > Can it be fixed?

  If it is wrong sure.

> > Am I over reacting?

yes/no, It may matter.  Simple tests point to potential
problems.  Most often it will be your test.. but not always.

Any author needs to do some basic numerical analysis of his
application.  As the exponents vary by orders of magnitude
it matters more and more.

Just use good sense, good science and caution. Try to not to
look silly with sample code that "does not correctly"
compare or converge at the last (15th) digit and yet defines
pi as 3.14159 in one file and 3.1415 in another.

Modern compilers will try to keep things in registers.  On
intel hardware 80 bit registers may come to play. On other
machines instructions like multiply+add (SGI/HP/IBM, madd)
might operate on 'hidden' bits.  Some MIPS (sgi) processors
round on the store so the MADD instruction gets to operate
on extra guard hidden bits in normal mode.  This can cause
data mis-matches in the last bit depending on the
library/optimization/debugger.

Most quant chem classes spend weeks on accuracy and
precision issues.  Build those lessons into your
applications and test suites.  Consider basic numerial
analysis tests too (call a math guy this is hard stuff).

This also matters for multi processing where the order of
execution is decomposed and different results are seen with
different processor counts because of rounding and joining
of partial results.  Sometimes the difference is startling
and discovers flaws in the code.  Run your code and data on
as many machines and numbers of processors as you can.
Understand the differences.  Finds ways to tinker with the
data set to understand the envelope of the code.  Build data
sanity checkers.

Experiment.... try operating on a list of very large and
very small numbers (+16, 32 or 100 orders of magnitude
different). Sort them and sum,randomize them and sum, sort
inverted and sum. Decompose for multiprocessor suming...
(sum of sums).

Then look at what you are doing in your code.

Note that ieee defines multiple rounding modes....
These can be tested for and specified on various 
systems.

Avoid dividing by zero... there is no correct answer for 4/0
yet ieee does define some 'legal' actions, understand NaN.

Have fun,
mitch



------------------------------

From: Graham Stoney <[EMAIL PROTECTED]>
Crossposted-To: comp.arch.embedded,comp.sys.powerpc.tech
Subject: Re: Advice on PowerPC MPC823 Dev. Tools?
Date: 29 Mar 2000 04:31:37 GMT

>On Fri, 24 Mar 2000 20:00:42 GMT, Casey Smith <[EMAIL PROTECTED]>
>wrote: 
> Hi there.... I'm building USB-MIDI device based around a MPC823. 
>Does anyone have any experience with the various development tools
>available from Motorola and third party vendors? 

There are lots of good options. I've written a HOWTO for embedded PowerPC
based Linux systems, which you might find helpful. You can check it out at:

    http://members.xoom.com/greyhams/linux/PowerPC-Embedded-HOWTO.html

I'd be very interested in any feedback readers here had.

Regards,
Graham

------------------------------

From: "Marc E. Christensen" <[EMAIL PROTECTED]>
Subject: libpcap in so format?
Date: Tue, 28 Mar 2000 22:12:36 -0700

I have made some RPMs of libpcap for Caldera's OpenLinux eServer 2.3 and
noticed that the source only creates a static library.  I would like to
make a dynamic one and would like to pathch the makefile to do so,
however, I don't know how to make dynamic libraries.  What is nessasery
to make a '.so' instead of a '.a'?

Thanks.

--
Marc C.
An Official LDP Mirror:
http://www.mecworks.com

------------------------------

From: "Marc E. Christensen" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: How do I make shared libraries?
Date: Tue, 28 Mar 2000 22:17:45 -0700

I have recently made some RPMs of libpcap for Caldera's OpenLinux
eServer 2.3 and noticed that the source only creates a static library. 

I would like to make a dynamic library in addition to the static one and
would like to patch the makefile to do so, however, I don't know how to
make dynamic libraries.  What is nessasery to make a '.so' instead of a
'.a' on Linux with egcs-2.91.66?

Thanks.

--
Marc C.
An Official LDP Mirror:
http://www.mecworks.com

------------------------------

From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: Windows CE target for GCC?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 29 Mar 2000 06:18:19 GMT

Centuries ago, Nostradamus foresaw a time when Tuomas Airaksinen would say:
>Thu, 16 Mar 2000 08:08:25 GMT, Tom & Ada Campbell kirjoitti:
>>Is there version of GCC that can output Windows CE executables?
>
>Can you put Linux on Windows CE-machine???
>I suppose you can't...

You suppose wrong...

<http://www.linuxce.org/>
-- 
"Computer science is like library science -- you create a problem and then
study it." -- David Place
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>

------------------------------

Date: Wed, 29 Mar 2000 00:45:15 +0000
From: "Arthur H. Gold" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: How do I make shared libraries?

"Marc E. Christensen" wrote:
> 
> I have recently made some RPMs of libpcap for Caldera's OpenLinux
> eServer 2.3 and noticed that the source only creates a static library.
> 
> I would like to make a dynamic library in addition to the static one and
> would like to patch the makefile to do so, however, I don't know how to
> make dynamic libraries.  What is nessasery to make a '.so' instead of a
> '.a' on Linux with egcs-2.91.66?
> 
> Thanks.
> 
> --
> Marc C.
> An Official LDP Mirror:
> http://www.mecworks.com
Make sure that your *.o files are compiled with the -fPIC option to gcc.
Then link (libyourlib.so) with the options -nostartfiles -shared.

That should get you started.

HTH,
--ag

BTW - the whole deal is in the ELF HOWTO (IIRC)
-- 
Artie Gold, Austin, TX  (finger the cs.utexas.edu account for more info)
mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED]
--
A: Look for a lawyer who speaks Aramaic...about trademark infringement.

------------------------------

From: Tim Harvey <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Recomendation for a graphical 'diff' style program for Linux?
Date: Tue, 28 Mar 2000 22:49:22 -0800

Greetings,

I'm looking for recomendations for a nice graphical diff program for
Linux.  I'm looking for something very close to 'Beyond Compare' for
windows or like the diff that comes on an Irix system.  I'm aware of
'kdiff' but it doesn't have the features I'm looking for.  I'm looking
for something that can diff directories as well as files, and that can
allow you to edit files by moving diffs back and forth between right and
left panes.

Any suggestions?

Thanks,

Tim
[EMAIL PROTECTED]


------------------------------

From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Recomendation for a graphical 'diff' style program for Linux?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 29 Mar 2000 07:04:53 GMT

On Tue, 28 Mar 2000 22:49:22 -0800, Tim Harvey <[EMAIL PROTECTED]> wrote:
>Greetings,
>
>I'm looking for recomendations for a nice graphical diff program for
>Linux.  I'm looking for something very close to 'Beyond Compare' for
>windows or like the diff that comes on an Irix system.  I'm aware of
>'kdiff' but it doesn't have the features I'm looking for.  I'm looking
>for something that can diff directories as well as files, and that can
>allow you to edit files by moving diffs back and forth between right and
>left panes.
>
>Any suggestions?

My suggestion is to learn the non-graphical tools for doing these things, while
continuing in your search for the graphical tools. 

The diff3 program (given the right option) will take three files and produce a
merged result with conflicts delineated by special markers. It's simple to edit
the text to resolve the conflicts.

To use diff3, you need three versions of the file. A common ancestral version,
and two independent edits based on that old version.

The CVS version control system has merging built in. Speaking of which, the
cvsweb front end for CVS has graphical diffing; it's web based though.

-- 
#exclude <windows.h>

------------------------------

From: Mats Byggmastar <[EMAIL PROTECTED]>
Subject: Re: UART overrun errors
Date: Wed, 29 Mar 2000 09:16:19 +0200

Mats Byggmastar wrote:

> This would give more than one second buffering on rx at 64 kbit/s.

Uhm.. make that over 100 ms buffering.


Mats

------------------------------

From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: BIOS support
Date: 28 Mar 2000 23:18:17 -0800
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)

Followup to:  <[EMAIL PROTECTED]>
By author:    Robert Redelmeier <[EMAIL PROTECTED]>
In newsgroup: comp.os.linux.development.system
>
> Mark Langsdorf wrote:
> >     How much of the BIOS does Linux require to load the kernel
> > image, then?  Just enough to get the GP-BUS and SDRAM set up,
> > or something more?  If one were trying to to write a pared down
> > BIOS to boot Linux, could the VGA or floppy drive controller be
> > left off?
> 
> Loading the kernel is the easy part.  Just load the MBR (LILO boot.s)
> at 0x00007C00 and jump there.  BIOS has _alot_ of work to do before
> it can get there.
> 

Uh... hardly so.  LILO et al use the BIOS to load the kernel!  You'd
be much better off bypassing LILO and load the kernel yourself.  You
also need to modify setup.S to not use the BIOS.

> First, the BIOS must test the hardware, and size RAM.  Then it
> must program the Northbridge and southbridge (load config registers,
> mostly from CMOS, but some from the SDRAM SPD ROM).  There alot
> of PIC, PIT, DMA, etc chips virtualized that must be setup correctly.
> Then it can find and run all the adapters (cards) initialization 
> routines.
> 
> This is all extremely board & chipset specific.  If you don't do it,
> the PCI bus will probably be dead, and I doubt Linux will be able
> to bring it to life.  Some BIOSes have a protected boot block for
> failed flashes.  An ISA VGA card will work, but that's it.  I do 
> wish the OpenBIOS folks luck. 
> 

Oh, this indeed true.

        -hpa
-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."

------------------------------

From: "David Brown" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch.embedded,comp.sys.powerpc.tech
Subject: Re: Advice on PowerPC MPC823 Dev. Tools?
Date: Wed, 29 Mar 2000 09:37:17 +0200

Richard Hendricks wrote in message <[EMAIL PROTECTED]>...
>
>
>Matt Porter wrote:
>>
>>
>> For the FADS case, note that Mot is notoriously slow at updating public
web
>> information so the best way to find out about it is to contact MV.
>
>What, precisely, needs to added to our website?  Let me know and I'll
>beat the webmistress into submission.  But you're right, we've had
>problems getting stuff out there.  Motorola is transitioning to a
>Brave, New Web, which is supposed to help customers find data easier,
>and make it easier for us workers to add to it.
>

Motorola has had trouble with its website for as long as I have used it.  It
is not alone - most big manufacturers have websites that are a pain to use
at least in some ways.  Once you know where things are on the Motorola
website, it's fine to use - until it moves.  Finding things can be
counter-intuative, though.  For example, who would have thought that while
the 68332 is classified as a "microcontroller", whereas the the 68328 is
obviously a "microprocessor"?

Motorola can also be very slow at updating their website.  I remember trying
to look up the electrical specs for the 25 MHz 68332 I had mounted on a card
on my desk, only to find the web site proudly announcing the new release of
the 20 MHz version!

Still, it's all there if you look.  Dig hard enough and you'll find things
like prehistoric (well, pre-1990) assemblers and application notes in the
terrible cgi format - they never seem to throw anything away.


>> --
>> Matt Porter
>> [EMAIL PROTECTED]
>> This is Linux Country. On a quiet night, you can hear Windows reboot.



------------------------------

From: Andreas Kahari <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: How do I make shared libraries?
Date: Wed, 29 Mar 2000 07:49:27 GMT

In article <[EMAIL PROTECTED]>,
"Marc E. Christensen" <[EMAIL PROTECTED]> wrote:
> I have recently made some RPMs of libpcap for Caldera's OpenLinux
> eServer 2.3 and noticed that the source only creates a static library.
>
> I would like to make a dynamic library in addition to the static one
and
> would like to patch the makefile to do so, however, I don't know how
to
> make dynamic libraries. What is nessasery to make a '.so' instead of a
> '.a' on Linux with egcs-2.91.66?
>
> Thanks.
>

I'm more used to downloading GNU source arhieves directly off the GNU
mirrors. When I do that I often get to run a 'configure' script to
create the Makefiles. The flags for that script may sometimes include a
flag for building a static/shared version of libraries.

/A

--
# Andreas K�h�ri, <URL:http://hello.to/andkaha/>
# Scandinavinans, without us "thursday" wouldn't exist!


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Wolfram Gloger <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Zero padding in sprintf() doesn't work for strings - HELP !
Date: 29 Mar 2000 10:53:20 +0200

[EMAIL PROTECTED] (bill davidsen) writes:

>   Note that the man page clearly says that it does work the way he
> expects.

As I've said before, the man page is misleading, and this is the real
bug.  I've sent a patch that should clarify the situation in the next
man-pages release.

> I'm not sure that the ANSI standard says the same thing, when I
> left the committee the sense was that it wouldn't be required to act
> that way, but the man page is totally clear.

The ANSI standard does not say the same thing.  In the next man-pages
release, they will agree, though.

Regards,
Wolfram.

------------------------------

From: Eugene Morozov <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Recomendation for a graphical 'diff' style program for Linux?
Date: 29 Mar 2000 13:55:50 +0400

Tim Harvey <[EMAIL PROTECTED]> writes:

> Greetings,
> 
> I'm looking for recomendations for a nice graphical diff program for
> Linux.  I'm looking for something very close to 'Beyond Compare' for
> windows or like the diff that comes on an Irix system.  I'm aware of
> 'kdiff' but it doesn't have the features I'm looking for.  I'm looking
> for something that can diff directories as well as files, and that can
> allow you to edit files by moving diffs back and forth between right and
> left panes.
I think that Emacs ediff has most of the features you want (if not
all). 
Eugene

-- 
Email: <jmv @ lucifer dorms spbu ru> Homepage: http://lucifer.dorms.spbu.ru

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list (and comp.os.linux.development.system) via:

    Internet: [EMAIL PROTECTED]

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Development-System Digest
******************************

Reply via email to