Sun-Spots-Request@Rice.edu (William LeFebvre) (09/30/88)
SUN-SPOTS DIGEST Wednesday, 28 September 1988 Volume 6 : Issue 241
Today's Topics:
Re: emulated floating-point on Sun 4
Re: Hanging serial multiplexor
Re: Bigger icons for frames
Still more on bigger icons for frames
locking with fcntl(2) is slow
NULL's in a file
Sun DVMA?
PC-NFS & Western Digital 8003 e-net board?
wanted: more interesting screen saver
Send contributions to: sun-spots@rice.edu
Send subscription add/delete requests to: sun-spots-request@rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY". They are also accessible
through the archive server: mail the request "send sun-spots vXnY" to
"archive-server@rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Sat, 24 Sep 88 00:25:35 EDT
From: attcan!utzoo!henry@uunet.uu.net
Subject: Re: emulated floating-point on Sun 4
My acquaintance within Sun (who definitely does *not* speak officially for
Sun) reports that looking ahead to the next instruction before returning
from the floating-point emulator is, by itself, not very helpful. The
trouble is that the compilers, with an eye on parallelism in hardware
implementations, tend to interleave floating-point and integer
instructions, so consecutive floating-point instructions aren't common.
(We didn't have this problem on the pdp11, since the compiler wasn't that
smart...) If one were willing to emulate integer instructions too, that
might help. Such variations are being looked at.
Henry Spencer at U of Toronto Zoology
uunet!attcan!utzoo!henry henry@zoo.toronto.edu
------------------------------
Date: Sat, 24 Sep 88 14:44:31 EST
From: Ross Johnson <munnari!cancol.oz.au!ross@uunet.uu.net>
Subject: Re: Hanging serial multiplexor
Reference: v6n225
In v6n225 Chris Brown describes a problem concerning 'unexpected
interrupt' on his MTI (multibus) serial board.
I had this same problem occurring a couple of times a day. It went away
when I replaced the 8085 CPU. It was a different brand name 8085 but I
can't say if that's what cured it.
Ross Johnson
ross@cancol.oz.au
------------------------------
Date: Fri, 23 Sep 88 22:58:55 CDT
From: vixen!ronbo@cs.utexas.edu (Ron Hitchens)
Subject: Re: Bigger icons for frames
In v6n233 Mike Jipping <jipping@cs.hope.edu> responded to someone else
about defining larger than normal icons:
> This is how Fig does it with it's huge icon, ...
Well, shucks, since I'm the one who created Fig's icon, I figure I ought
to respond to this.
History first: Fig began its life as a class project by Supoj Sutanthavibul
(aka Paul) at the University of Texas in Austin. At that time I was on
the CS Unix staff there as the Sun and Mac Guru. This was way back in the
pre-SunView days when it was proper to access the various window data
structures directly. I helped Paul get started with Sun Windows (as it
was called then) and gave him some advice on the early design of Fig. The
icon editor at that time sucked royally, and I happened to have written a
tool to extract Sun icons from MacPaint files. So, I whipped up a
fanciful image for Fig on a Mac, uploaded it to the Sun and extracted it
with my tool. The image I created was too big to fit in 64x64, so I made
it bigger than normal just so it would make sense. It was a quick hack,
and not intended to be the real icon for Fig, but it was never replaced.
Fig itself wasn't originally intended for public consumption, but Paul did
such a good job on it that everybody wanted to use it.
So, that's why the Fig code sets up an icon data structure directly, but
how do we do it using the proper SunView method? Well Mike, you where 90%
of the way there. The underlying icon data structure really hasn't
changed under SunView. Here's the struct from
/usr/include/suntool/icon.h:
struct icon {
short ic_width, ic_height; /* overall icon dimensions */
struct pixrect *ic_background; /* background pattern (mem pixrect) */
--> Rect ic_gfxrect; /* where the graphic goes */
struct pixrect *ic_mpr; /* the graphic (a memory pixrect) */
Rect ic_textrect; /* where text goes */
char *ic_text; /* the text */
struct pixfont *ic_font; /* Font with which to display text */
int ic_flags;
};
The key item here is the ic_gfxrect field. This field is not set by the
icon attributes ICON_WIDTH and ICON_HEIGHT, they only affect the icon
pixwin size. The icon you see on the screen is actually the frame's
pixwin which is resized and moved when the tool goes iconic. The field
ic_gfxrect indicates where to raster_op the ic_mpr pixrect into the
pixwin. You have to set ic_gfxrect with the attribute ICON_IMAGE_RECT if
you want to use something other than the default 64x64 rectangle that the
image pixrect is rop'ed into.
If you look at /usr/include/suntool/icon.h, you can see how the attributes
map to the fields of the icon struct. Unfortunately, there doesn't seem
to be SunView/attribute method to set the ic_background or ic_flags
fields. In the fragment of Fig code above, the ic_flags field is being
set so that a black border is drawn around the icon. By using data types
defined in icon.h you can get to them, but that could cause portability
problems later.
I whipped up a little toy program to demonstrate how to make non-standard
sized icon with SunView calls, it's included below. This code takes two
regular icons, combines them into another pixrect side-by-side, then
centers that image in a slightly larger icon window so that there is a two
pixel border around everything. This guy also modifies the ic_flags so
that the border is painted black. If your icon image fills the window,
there is no need to mess with the flags. If the icons that it includes
are not available to you for some reason, substitute any two icons of your
choice. (BTW, the Sun logo and arrow appear to overlap, but that's merely
an optical illusion).
__________
/*
* Test big, fat icons
*
* Ron Hitchens ronbo@vixen.uucp hitchens@cs.utexas.edu
*/
#include <stdio.h>
#include <suntool/sunview.h>
#include <suntool/canvas.h>
/*
* We're gonna make an icon big enough for two side-by-side regular icons
* plus a two pixel border all around.
*/
#define MY_ICON_WIDTH (ICON_DEFAULT_WIDTH * 2) + 4
#define MY_ICON_HEIGHT ICON_DEFAULT_HEIGHT + 4
/* The Sun logo */
static short image1 [] = {
#include <images/lockscreen.icon>
};
mpr_static (pr1, ICON_DEFAULT_WIDTH, ICON_DEFAULT_HEIGHT, 1, image1);
/* a big double ended arrow */
static short image2 [] = {
#include <images/switcher.icon>
};
mpr_static (pr2, ICON_DEFAULT_WIDTH, ICON_DEFAULT_HEIGHT, 1, image2);
/*
* Icon's image rect within the displayed icon pixwin, offset 2 pixels from
* the top left corner, twice as wide as standard.
*/
Rect ic_rect = { 2, 2, ICON_DEFAULT_WIDTH * 2, ICON_DEFAULT_HEIGHT };
main (argc, argv)
int argc;
char **argv;
{
Frame frame;
Canvas canvas;
Icon icon;
icon_handle ic_handle;
Pixrect *pr;
pr = mem_create (ICON_DEFAULT_WIDTH * 2, ICON_DEFAULT_HEIGHT, 1);
pr_rop (pr, 0, 0, ICON_DEFAULT_WIDTH, ICON_DEFAULT_HEIGHT, PIX_SRC,
&pr1, 0, 0);
pr_rop (pr, ICON_DEFAULT_WIDTH, 0, ICON_DEFAULT_WIDTH,
ICON_DEFAULT_HEIGHT, PIX_SRC, &pr2, 0, 0);
icon = icon_create (
ICON_IMAGE, pr,
ICON_IMAGE_RECT, &ic_rect,
ICON_WIDTH, MY_ICON_WIDTH,
ICON_HEIGHT, MY_ICON_HEIGHT,
0);
/* Convert the opaque Icon handle into a pointer-to-icon type */
ic_handle = (icon_handle) icon;
/* Set the icon surface-prep flags to paint black */
ic_handle->ic_flags = ICON_BKGRDSET;
frame = window_create (NULL, FRAME,
FRAME_LABEL, "Icon Test",
FRAME_ICON, icon,
FRAME_ARGC_PTR_ARGV, &argc, argv,
0);
canvas = window_create (frame, CANVAS,
CANVAS_RETAINED, FALSE,
0);
window_main_loop (frame);
exit(0);
}
Ron Hitchens ronbo@vixen.uucp hitchens@cs.utexas.edu
------------------------------
Date: Fri, 23 Sep 88 13:36:23 PDT
From: mtxinu!sybase!kiwi!barry@ucbvax.berkeley.edu (barry klawans)
Subject: Still more on bigger icons for frames
There has been alot of discussion of oversized icons recently. One recent
article mentioned the icon_load() routine.
> Make sure that you fix up the header in the icon file, since the
> icon_load() routine (undocumented, but available in <suntool/icon_load.h>)
> uses these numbers to create the initial icon pixrect. If you get the
> ICON_{WIDTH,HEIGHT} set right, it should work; I've created icons of all
> sorts of sizes this way.
Actually, the icon_load() routine (as well as several other useful icon
related routines) is documented in chapter 11 of the _SunView System
Programmer's Guide._ (My copy is marked "Revision A of 15 October 1986"
but I assume this material is still in newer versions. Look in the
chapter on "Advanced Imaging.")
In article <1906@kalliope.rice.edu> jippings@cs.hope.edu writes:
>Two followup questions: Are we talking about the COMMENT at the top of
>iconedit-generated files? And what does this mean about non-standard
>bitmap files?
The first COMMENT line at the beginning of an icon file is read by the
various icon loading routines, and must be correct if the icon is to be
loaded correctly. If there are more than one comment line all the
additional lines are ignored. In fact this is the only way for enough
information about non-standard bitmap files to be communicated to the
loader.
>So far, I'm following the book. Now I create the icon with "icon_create":
>
> bibtool_icon = icon_create(ICON_IMAGE, &bibtool_icon_pr,
> ICON_WIDTH, 105,
> ICON_HEIGHT, 67,
> 0);
I would guess that the problem with this is the order of the attributes.
I'm assuming that it copies the image as soon as the ICON_IMAGE attribute
is seen, in which case in this example it still thinks that the icon is a
standard 64x64 image. Try defining the width and height before you
specify the image and it may work.
If that fails create the icon with ICON_WIDTH and ICON_HEIGHT set the
values you want, but do not specify ICON_IMAGE. Then you can use the
icon_load() routine to load the image from the file into the icon. I've
tried this and it works. It has the additional benifit that you do not
need to declare the bibtool_icon_pr, so you do not tie up that storage.
Barry Klawans
Sybase Inc.
UUCP: {mtxinu,sun,pyramid,pacbell}!sybase!barry
------------------------------
Date: 24 Sep 88 05:27:23 GMT
From: munnari!munginya.cs.mu.oz.au!jayen@uunet.uu.net (Jayen Vaghani)
Subject: locking with fcntl(2) is slow
I'm trying to do some record and page locking using fcntl(2) on Sun 4/110
and it is turning out to be incredibly slow. Releasing or taking a lock
seems to take on the order of 5ms even when there is no other lock present
in the system. It's even slower on a Sun 3/140 - about 15ms. The files
being locked are on disks directly connected to the respective Suns so
there should be no network traffic involved.
Can someone offer some suggestions as to what is going wrong? I've
included below the test program I'm using. This program takes just over a
second (real time) to run on an Encore which has a slower cpu, but takes
20 seconds on the Sun 4. System on the encore is about 1.3 but is about
8.9 on the Sun 4. Using ps while the process is running, seems to
indicate that it spends most of its time on disk, for some reason. Does
this mean the kernel is electing to always swap out the process when a
record lock is requested?
Thanks, Jayen.
__________
#include <fcntl.h>
struct flock lock;
main()
{
register int i;
int fd;
lock.l_type = F_RDLCK;
lock.l_whence = 0;
lock.l_start = 100;
lock.l_len = 100;
fd = open("lock.c", 0);
for (i = 0; i < 2000; i++)
{
if (fcntl(fd, F_SETLK, &lock) < 0)
{
perror("");
exit(1);
}
lock.l_type = F_UNLCK;
if (fcntl(fd, F_SETLK, &lock) < 0)
{
perror("");
exit(1);
}
}
}
__________
UUCP: {uunet.uu.net,ukc,ubc-vision,mcvax}!munnari.oz!jayen
ARPA: jayen%munnari.oz@uunet.uu.net
CSNET: jayen%munnari.oz@australia
Jayen Vaghani Home Address: 28 Estelle St
Department of Computer Science East Oakleigh, Vic, 3166
University of Melbourne Australia
Grattan St Phone: + 61 3 344-7877 (BH)
Parkville, Vic, 3052 + 61 3 569-6512 (AH)
------------------------------
Date: Sat, 24 Sep 88 02:17:55 PDT
From: portal!jel@sun.com (John Little)
Subject: NULL's in a file
We have found two reasons that NULLs can appears in a file.
The first is a bug in the Xylogics 450 controller. Under heavy load, the
controller will return a block (8K) of NULLS but not report an error.
This is antisocial, to say the least. Xylogics supposedly has new
firmware that fixes this problem. Before we learned of the fix, however,
we bought some Ciprico controllers. When we saw the performance we could
get with a "real" controller, we had little interest in fixing the 450's.
The second is caused by tail'ing an NFS mounted file that is being written
to. This has been discussed before in Sun-Spots, but I am repeating it to
mention that it happens to us with a combination of Sun 3's running 3.4
and 3.5.
John Little
Portal Communcations
jel@portal.com
------------------------------
Date: Fri, 23 Sep 88 17:41:18 PDT
From: nomdenet@venera.isi.edu
Subject: Sun DVMA?
We are designing a device with more than 100MB of RAM and are concerned
with moving data to & from it as rapidly as possible. So I've been
looking at DVMA. I've read chapter 2, "Hardware Context," in "Writing
Device Drivers," and think I understand things, but want to ask some
questions of you Sun wizards out there to be sure.
1) The manual refers to the "main bus" but never describes it explicitly.
Is it the bus on the processor card connecting the CPU, on-board
memory, the Ethernet and any other on-board I/O controllers?
2) Since DVMA addresses go through the memory management unit, it appears
that DVMA is possible only between:
- an onboard DVMA master and onboard memory;
- an onboard DVMA master and outboard (VMEbus-resident) memory; and
- an outboard DVMA master and onboard memory.
True? False? Something else?
3) Can VMEbus boards other than the processor card be bus masters?
I would assume so since there are disk and tape controllers.
4) If the answer to 3) is "yes," is non-virtual DMA possible between
VMEbus-resident boards using 32-bit physical addresses?
5) Can the Ethernet and/or an outboard disk controller be made to transfer
data to/from outboard memory?
Replies to me, please, not the digest. If there's enough interest I'll
summarize.
Thanks,
A. R. White
USC/Information Sciences Institute
4676 Admiralty Way
Marina Del Rey, California
90292-6695
(213) 822-1511, x162
ARPA: nomdenet @ ISI.edu
------------------------------
Date: Fri, 23 Sep 88 08:29:00 CDT
From: apctrc!phred!drd!mark@uunet.uu.net (Mark Lawrence)
Subject: PC-NFS & Western Digital 8003 e-net board?
Whenever we have the ethernet board installed, our com ports fail to work.
We've tried different IRQ level settings. Anybody else run into this?
Mark Lawrence
DRD Corporation @ 5506 South Lewis | [uunet!apctrc,romed,tulsun]!phred!mark
Tulsa, IT 74105 (918)743-3013 | mlawrence@jarsun1.ZONE1.COM
------------------------------
Date: Sat, 24 Sep 88 13:08:56 PDT
From: grand!day@uunet.uu.net
Subject: wanted: more interesting screen saver
I'm tired of "The Game of (Sun) Life". Surely there must be something
more interesting out there (no, not the /usr/demo programs), like the
"stars" screen saver on the mac, or the human ant farm on the Commodore
64, or ... Show us your screen savers!
--dave yost
------------------------------
End of SUN-Spots Digest
***********************