Subject: hardware independent hinv

From: [email-masked] (Ariel Faigon)
Date: Wed, 28 May 1997 08:17:44 -0700 (PDT)

Just forwarding since it sounds someone hopes that Linux/MIPS
will some day have a HW independent hinv... - Ariel

----- Forwarded message from Dave Olson -----

>From olson@anchor  Mon May 12 13:50:21 1997
Date: Mon, 12 May 1997 13:50:18 -0700
From: olson@anchor (Dave Olson)
Message-Id: <[email-masked]>
To: olson@anchor (Dave Olson), [email-masked]
Subject: Re: missing machfile
Cc: swmgr@swmgr, breyer@swmgr, ariel@cthulhu
References: <[email-masked]>
    <[email-masked]>
    <[email-masked]>

|  I would assume that hinv is hardware-dependent, because of the
|  mapping issues?  Or is it table driven off of an analogue of the machtab?

Still all compiled in.  Bug/rfe open for years now about making it table
driven.

|  Unfortunately, nothing better is generally available across
|  platforms and releases.

Yes, and that's something that would be nice to fix.  Maybe linux will
do it, and we can copy them.

|  D> Lots, for any non-trivial app.  They don't have to, but often want to.
|  
|  ???  Non-trivial as in "big and powerful", or as in "gets close to
|  the hardware"?  I would argue that emacs and perl both fit the

Both/either.  Not all  big apps, of course.

|  I was looking at the options to uname, specifically "-p".  Based
|  upon the man page, shouldn't `uname -p` return "mips3" instead of
|  "mips" for my IP22?  That is one obvious meaning for:

Yes, but then you break even more of the configure scripts.  Again,
a no-win situation.

|  I was just curious is there was somehow we could make life easier
|  for configure scripts to port software for IRIX...  On the other
|  hand, we generally only get bad comments about /bin/install, and at
|  least we *don't* get comments like:

|  # AIX cpp loses on an empty file, so make sure it contains at least a newline.
Using cpp is a horrible solution...

|  It is hard to add functionality without breaking stuff.

A programmer's lament, if I ever heard one!

Dave Olson, Silicon Graphics   Guru and busybody at large
http://reality.sgi.com/olson   [email-masked]

----- End of forwarded message from Dave Olson -----

-- 
Peace, Ariel

---

From: Mike Shaver <[email-masked]>
Date: Wed, 28 May 1997 11:35:27 -0400 (EDT)

> will some day have a HW independent hinv... - Ariel

Do they need more than the /proc stuff?
Larry has a perl version of hinv that reads from /proc/whatever, I
seem to recall.

Mike

-- 
#> Mike Shaver ([email-masked]) Ingenia Communications Corporation 
#>                   Welcome to the technocracy.
#>                                                                     
#> "you'd be so disappointed
#>              to find out that the magic was not
#>                          really meant for you" - OLP

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 28 May 1997 18:03:20 +0200 (MET DST)

> will some day have a HW independent hinv... - Ariel

Larry has shown me a perl script on his Linux/i386 box which does just
this.  I intend to supply the information required by such a script
via the proc filesystem.

  Ralf

> |  "mips" for my IP22?  That is one obvious meaning for:

Q: what exactly does that IP?? notation stand for?  Internal model names,
CPU modules, ???

> Yes, but then you break even more of the configure scripts.  Again,

You're absolutely right.  For just that reason I changed the output for
little endian MIPS boxes from mipsel to mips a long time ago though
mipsel is logic when thinking of the generic GNU configuration names.

> |  least we *don't* get comments like:

After the last few days I can say that porting to IRIX is a quite boring
job; most things just work.  Only ssh makes problem.  Solved by using
GCC (snapshot) instead of SGI's cc.

> Using cpp is a horrible solution...

Tell the people who invented imake ...

> A programmer's lament, if I ever heard one!

Or break what's broken ...

  Ralf

---

From: Miguel de Icaza <[email-masked]>
Date: Wed, 28 May 1997 12:42:17 -0500

> Larry has a perl version of hinv that reads from /proc/whatever, I

Yesterday I went to see some guy running the University's new Origin
machine, and they showed me some monitoring tools on IRIX, very
impressive tools.  I want them on Linux :-).

There was this lovely tool that showed the memory map, with the
details on the usage.  You could click on say, Emacs, and get a map of
where Emacs pages were, and it seemed like it could read the symbol
table information from the process as well (it showed: "No symbols for
this page").

I also saw some printed slides on some program that seemed to let you
move related functions together in the binary to avoid page faults.
Can not really tell, as they were flipping trough them really quick.

I remember attending a presentation at Usenix where they talked about
this very feature.  This is something else we want in our binutils.

Miguel.

---

From: "David S. Miller" <[email-masked]>
Date: Wed, 28 May 1997 14:18:27 -0400

Date: Wed, 28 May 1997 12:42:17 -0500
   From: Miguel de Icaza <[email-masked]>

   I also saw some printed slides on some program that seemed to let
   you move related functions together in the binary to avoid page
   faults.  Can not really tell, as they were flipping trough them
   really quick.

   I remember attending a presentation at Usenix where they talked
   about this very feature.  This is something else we want in our
   binutils.

The solaris dynamic linker does this at run time, it collapses
together only the functions/data which your program could ever
reference into one contiguous chunk of pages.  I haven't worked out
the complete set of details of how this is done completely at run
time, and efficiently as well, but I have spoken to Eric Youngdale and
other Linux userland experts about this trick.

---

From: Miguel de Icaza <[email-masked]>
Date: Wed, 28 May 1997 14:49:01 -0500

> reference into one contiguous chunk of pages.  

Mhm, you mean, it moves the functions and data around?  This looks
interesting.  How does the Solaris linker find this out?

On the presentation at Usenix, they used feed the profiling
information into this executable-reorganizer program and the output
was this "optimized" executable.

Actually, I just found the program, from the cord(1) man page: 

     In the example below, a program foo is run through pixie(1) which
     generates foo.pixie.  The instrumented executable is run and prof is used
     to produce a feedback file from the profiled data.  Cord is then used to
     reorder the procedures in foo, generating a new binary foo.cord.

            pixie foo
            foo.pixie
            prof -pixie -feedback foo
            cord foo foo.fb

Pretty cool.

In the paper they presented some other optimizations to dynamically
linked programs.  Let me see if I can get the paper from the Usenix
site.

Cheers,
Miguel.

---

From: Martin Knoblauch <[email-masked]>
Date: Fri, 30 May 1997 09:14:50 +0200

> table information from the process as well (it showed: "No symbols for

 That would be "gmemusage" (in a former life "bloatview", with
some really cool desktop icons. Maybe for Linux, we could replace
the pigs with a real fat penguin :-).

> Can not really tell, as they were flipping trough them really quick.

 That tool is "cord". It uses feedback from prof/pixie experiments.

Martin
-- 
Check out the DevForum 97  !!!! (http://www.sgi.com/Forum97/)
  If you miss it, you'll never forgive yourself. Neither will I :-)
+---------------------------------+-----------------------------------+
|Martin Knoblauch                 | Silicon Graphics GmbH             |
|Manager Technical Marketing      | Am Hochacker 3 - Technopark       |
|Silicon Graphics Computer Systems| D-85630 Grasbrunn-Neukeferloh, FRG|
|---------------------------------| Phone: (+int) 89 46108-179 or -0  |
|http://reality.sgi.com/knobi     | Fax:   (+int) 89 46107-179        |
+---------------------------------+-----------------------------------+
|e-mail: <[email-masked]>   | VM: 6-333-8197 | M/S: IDE-3150    |
+---------------------------------------------------------------------+