Re: Snowhite and the Seven Dwarfs - The REAL story!

[Patryk Zadarnowski]

On Tue, 30 Jan 2001, Mike Silbersack wrote:

> 
> On Wed, 31 Jan 2001, Dan Langille wrote:
> 
> > On 30 Jan 2001, at 3:19, Giorgos Keramidas wrote:
> >
> > > of filtering is necessary though.  Unless, somebody thinks that this is
> > > "censorship", and a new flame about humans rights spawns out of nowhere.
> >
> > We're not stopping anyone from saying anything.  We're just stopping
> > them from saying it on our lists.
> >
> > --
> > Dan Langille
> 
> Uh oh, I sense an argument over whether object files are expressive speech
> or functional tools coming on. :)

Definitely expressive speech. Which makes GCC a creative, intelligent
creature, doesn't it? ;)

Pat.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Patryk ZadarnowskiUniversity of New South Wales
<[EMAIL PROTECTED]> School of Computer Science and Engineering
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Snowhite and the Seven Dwarfs - The REAL story!

[Patryk Zadarnowski]

On Mon, 29 Jan 2001 00:23:48 -0800 (PST), Hahaha <[EMAIL PROTECTED]> wrote:

> Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and
> polite with Snowhite. When they go out work at mornign, they promissed a
> *huge* surprise. Snowhite was anxious. Suddlently, the door open, and the
> Seven Dwarfs enter...

That must be the most amusing Windows virus I've ever seen (it is a virus,
isn't it?).  Four spelling mistakes and five grammar problems in four lines of
text, probably sent to millions of people.

A few months ago someone suggested that all binary attachments should be
stripped from freebsd-hackers mail. I believe it is still a very good idea,
and patches tend to be posted as text anyway.

Pat.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Patryk ZadarnowskiUniversity of New South Wales
<[EMAIL PROTECTED]> School of Computer Science and Engineering
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Silent FreeBSD

[Patryk Zadarnowski]

On Wed, 27 Dec 2000, "Renaud Waldura" <[EMAIL PROTECTED]> wrote:

> I've got that FreeBSD gateway in a corner at my house, it works fine & dandy
> but the constant noise (whirring fans, hard drives) gets on my nerves.

> What solutions have people explored to quiet down a computer system? (actual
> experience will be preferred over wild speculations). I'm already aware of
> PicoBSD, but I need more storage than just a floppy. Has anybody
> experimented with RAM cards? How about noise-proof enclosures?

I knew a guy once who was doing sound work on an SGI box, and was constantly
complaining about the noise. He finally decided to eliminate everying that
moved in the box. The temperature in the case was so high he couldn't touch
some parts without getting burnt (don't remember the exact figures.) After
some smoke tests to establish the exact air flow, he ended up building a huge
wooden container with all walls insulated with a thick layer of foam and a 2
meter chimney to exhume the hot air. It worked like charm, although I think he
had to put one fan somewhere. The box was perfectly silent, and ran at a
comfortable 30 degrees C, but it took him a few months to get it working, and
he was a constant source of amusement to half the Uni population for a year.

Trust me, you don't want to attempt a noise-proof enclosure (short of an
air-conditioned machine room.) I suggest the following course of action:

1. get a quieter power supply
2. get a quieter fans
3. get a good new drives: they're quiet.
4. get used to the noise.

I have three computers running 24/7 in my bedroom, and after some swapping
of power supplies, the noise is perfectly bearable.

Pat.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Patryk ZadarnowskiUniversity of New South Wales
<[EMAIL PROTECTED]> School of Computer Science and Engineering
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: kernel type

[Patryk Zadarnowski]

On Sun, 17 Dec 2000, Tony Finch <[EMAIL PROTECTED]> wrote:

> Patryk Zadarnowski <[EMAIL PROTECTED]> wrote:
>> 
>> Now that I think of it, there aren't many commercial microkernel
>> systems out there with the possible exception of QNX and lots of
>> little embedded toys.

> Mac OS X is based on Mach.

Oh, that's right, that new kid on the block ;) I keep forgetting about
Apple's talent for shooting itself in a foot ;)

BTW, for the original poster: in case you don't know, there exists a
port of 4.4BSD that runs on top of Mach (Lites.)

Pat.

PS. Before this starts a flame war, let me say that I really believe
that MacOS X is a very good thing for everyone involved, although the
choice of Mach for the microkernel seems a little arbitrary if not
misguided.

Pat.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Patryk ZadarnowskiUniversity of New South Wales
<[EMAIL PROTECTED]> School of Computer Science and Engineering
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: kernel type

[Patryk Zadarnowski]

On Fri, 15 Dec 2000, "SteveB" <[EMAIL PROTECTED]> wrote:

SteveB> Sorry for such a basic question, but I have been looking and can't
SteveB> find the answer.  Is FreeBSD as microkernel or monolithic kernel like
SteveB> Linux?   Can someone point me to the answer/

It's a monolithic kernel, like Linux and all other mainstream UNIX
flavours except for OSF1 (ie. Digital UNIX or True64), which is based
on a hacked-up version of the MACH microkernel. Even then, most
microkernel researchers won't consider OSF1 a microkernel, as Digital
(now Compaq) worked around the MACH problem (which is an i-cache hog)
by moving much functionality back into the kernel. Now that I think of
it, there aren't many commercial microkernel systems out there with
the possible exception of QNX and lots of little embedded toys. NT,
sometimes claimed to be a microkernel, is far from it. Rather, it's
simply another reasonably-well structured kernel. With 300+ system
calls in the nucleus, the NT kernel handles just about everything
except for major GUI tasks.

Pat.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Patryk ZadarnowskiUniversity of New South Wales
<[EMAIL PROTECTED]> School of Computer Science and Engineering
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ANSI C Standard and wchar*

[Patryk Zadarnowski]

On Mon, 31 Jul 2000, "Michael C. Wu" <[EMAIL PROTECTED]> wrote:

Michael> Hi all,
Michael> I am working on completing a BSDL'ed implementation
Michael> of wchar* that is *not* broken.  However,
Michael> I could not find a free copy of ANSI C library standard.

Michael> I was wondering if anyone has an electronic copy of
Michael> ANSI/ISO/IEC 9899-1999 Programming Languages - C
Michael> and the related POSIX documents.  (Yes, the document
Michael> only costs $18 on ANSI.org, but I really do not want
Michael> to purchase something that I probably will not use again.)

Michael> Also, which part of POSIX governs the correct
Michael> behavior for wchar*? POSIX.1?

Michael> Finally, I know that someone has been working on the
Michael> same thing.  Would the person in question or someone please send
Michael> me what they have.

Michael> I apologize for the confusion. Many thanks.

Michael,

These standards are copyrighted, and  ANSI.org is very clear about the
electronic  copies being  for personal  use  only, not  to be  shared.
Considering that,  previously, you could not  buy ISO C  for less than
$300, having  a standards organization that  sees the light  is a good
thing, and, I suggest that we  all respect that. That is, you will not
(should not)  find anyone who'll  offer to share electronic  copies of
the standard.

I believe  that the answer to  your POSIX question is  "none". I don't
think POSIX deals with the wchar_t issue at all (someone correct me if
I'm wrong.)

Pat.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Patryk ZadarnowskiUniversity of New South Wales
<[EMAIL PROTECTED]> School of Computer Science and Engineering
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Is traditional unixes kernel really stable ?

[Patryk Zadarnowski]

> "Yevmenkin, Maksim N, CSCIO" wrote:
> 
> > only one :-) performance :-) context switch is a slow operation.
> > 
> > Thanks,
> > emax
> 
> 
> Excuse me gentleman, who said that ?
> Take time to visit this site: http://www.qnx.com/iat/download/index.html
> 
> You'll be introduced to a hard-real time OS (with a very modular
> design).
> The while OS fits in a single floppy with TCP/IP, GUI, web browser, http
> server, and again, all that in a single floppy. HOw can it be done?
> 
> This OS uses microkernel arch.
> Fill their form in order to get a book describing its OS internal arch.
> 
> Can some here explain me why such approach is not taken by FreeBSD?

Yes. FreeBSD is based on the BSD monolithic kernel. It's precisely the
``other camp'' to the u-kernel guys (like myself.) Hence the ``BSD''
in its name. ;)

Pat.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Patryk ZadarnowskiUniversity of New South Wales
<[EMAIL PROTECTED]>   School of Computer Science and Engineering
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Unicode on FreeBSD

[Patryk Zadarnowski]

> On Wed, 5 Apr 2000, G. Adam Stanislav wrote:
> 
> > >  Lack of extensibility and variants. Don't they just love the great
> > >extensibility means aka non-standardized and non-standardizable "private
> > >use area" that defeats the whole idea of having a standard charset?
> > 
> > Absurd! The private use area is for application specific usage.
> > Suppose you want to design a database of cleaning supplies. You create
> > a font for the use with your application, which will draw soap, mop,
> > towel, and things like that. These are not in Unicode, and your odds
> > of convincing the Consortium to include them are slim. So, your
> > application will assign points within the private use are to soap,
> > mop, towel, etc.
> 
>   This is what it was intended for, however this is not how it is used. I
> understand why Unicode Consortium is unlikely to include Klingon alphabet
> into "blessed" by them charset, however the use of private area for
> Klingon is hardly application-specific. When instead of fictional (even
> though relatively well-known) charset the question is about the
> representation of "obscure" or even hypothetic details of some real-world
> charset, things become much more hairy. Labeling of charsets and languages
> in multiple-charsets environment (even if in the case of Klingon the
> "charset" is Unicode with something added in the private area) can
> eliminate ambigiuty without involving ISO, Unicode consortium, etc. and
> without destabilizing "standards" by constant changes.

Can it? People have been begging ISO to standarise 8 bit charsets for ages.
If you tried to exchange information in polish in the pre-8859 days, you'd
know why (about five radically different charsets in common use) Besides, if
the alphabet for information interchange doesn't deserve standarising, I don't
know what does.

Pat.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Patryk ZadarnowskiUniversity of New South Wales
<[EMAIL PROTECTED]>   School of Computer Science and Engineering
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Unicode on FreeBSD

[Patryk Zadarnowski]

> >  I have just asked, who will benefit from it. No one answered "I will" --
> >everyone who makes Unicode support believes that it will benefit someone
> >else.
> 
> I thought I did. OK, let me restate: I will! I actually do already because
> I did some work and it is in the ports.

OK,  I didn't  say  anything ealier  because  I though  it was  fairly
obvious that anyone dealind with  a *mixed* environment beyond that of
ISO 8859-1 (even  if that means just a mixture  of ISO 8859-1/2) would
find Unicode support in the kernel a blessing from the heaven.  Let me
restate that:  I will use  it. Currently, if  you have a group  of ISO
8859-2  users on  the  system ,  the  ISO 8859-1  people  see them  as
meaningless junk.   I don't  even want to  think about  something like
Arabic.

Pat.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Patryk ZadarnowskiUniversity of New South Wales
<[EMAIL PROTECTED]>   School of Computer Science and Engineering
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Whatever happened to TenDRA?

[Patryk Zadarnowski]

> Hmm.  So I've compiled the TenDRA port, and I'm toying around with it,
> trying to get it to compile Qt (and perhaps gnu's libstdc++), but not
> suprisingly it seems to dislike some of the more basic (QList and QString
> and other template stuff) code in Qt, meaning even something as simple as
> moc can't be compiled.  So off I went to the TenDRA web page, but it seems
> to be down (can't connect, etc).  Has development on this compiler stopped
> or what?
> 

The project has been discontinued by DRA. I've set up a mirror of the site
(as it was last avaliable) at http://siliconbreeze.com/TenDRA/. Hope it's of
some help.

Pat.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Patryk ZadarnowskiUniversity of New South Wales
<[EMAIL PROTECTED]>   School of Computer Science and Engineering
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Why not gzip iso images?

[Patryk Zadarnowski]

> On Wed, 15 Mar 2000, Sheldon Hearn wrote:
> 
> > And you're forgetting that, as I said in my original reply, people with
> > 56K modems usually benefit from hardware compression over their link
> > anyway.
> 
> But you're defeated by your own argument, as according to you the image
> doesn't compress very well, and I suspect (in fact I know) that hardware
> compression at the modem is not as efficient as gzip -9 ... at best you
> might be able to get that 22Mb we're talking about saving, down to a 10Mb
> saving... you're still leaving the guy with the modem sat there for around
> 45 minutes...

Remember that our modem guy has spent the last 48 hours sitting there
waiting for the download to complete. I'm sure that by now he's fallen
asleep and the 45 minutes will not make a difference anyway. ;)

In most places that are ``affected'' by that 20MB you're trying to
save, bandwidth is so expensive that you'll never going to download
the ISO image anyway. I've just calculated that it would cost me AUD
120 or so, compared to $20 for downloading just the distribution I
need. If I was to download the ISO image over my modem, I'd order a CD
today instead (or enroll at Uni ;)

So I'm supporting uncompressed iso images. 99.99% of those who'd
benefit from the compression would never consider downloading them
anyway, and 99.99% of those who are going to use these images will
find .gz a pain.

Pat.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Patryk ZadarnowskiUniversity of New South Wales
<[EMAIL PROTECTED]>   School of Computer Science and Engineering
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 5.0 features?

[Patryk Zadarnowski]

> Mark Hittinger writes:
> >
> >Something that the old DEC took a few stabs at was the idea of a
> >"checkpoint" feature where a process or a series of processes could be
> >put in a quiesced state.  This would page out the process or processes
> >into the swap space, allow a hardware shutdown, and after a reboot allow
> >the restart of the checkpointed process(es).
> >
> 
> I did something like this for Philips while I was at UniSoft. It
> depended on some special hardware features (turning off/losing power
> generated an interrupt, there was a small UPS in the box along with
> battery-backed SRAM to save various kernel structures).
> 
> Turning off the power caused all memory to be saved to disk (the kernel
> turned off the UPS after it was done). Upon a restart the kernel noticed
> that memory had been saved, read the contents in from disk, futzed around
> with some structures, and restarted what was curproc at the time of
> shutdown. It even worked ;-)
> 
> Philips never did anything with it.

Out of pure curiosity, what did you do with pending interrupts, partially
completed DMA transfers and other such state information?

Pat.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Patryk Zadarnowski <[EMAIL PROTECTED]>   University of New South Wales
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> On Sun, 20 Feb 2000, Patryk Zadarnowski wrote:
> 
> > > On Sun, Feb 20, 2000 at 12:42:14PM +1100, Patryk Zadarnowski wrote:
> > > > One more thing about GPTs (I thought I'll leave that till last. ;)
> > > > Jochen Liedtke holds a German patent on them, although he will
> > > > probably be fairly easily convinced to give FreeBSD rights to use
> > > > them. I'll be happy to ask (if we're interested.)
> > > 
> > > It looks like the hardware has to implement GPTs and know how to
> > > walk them. How can FreeBSD use them without hardware support ?
> > 
> > No it doesn't. We've got software GPT implementations for both MIPS64 and
> > Alpha, and they're both peform very well in our somewhat hostile SASOS
> > conditions.
> 
> So you have custom PALcode for Alpha on SASOS? We have been able to use
> OSF1 PALcode up to now which makes life a lot easier for supporting new
> hardware.

Sure. Mungi (our SASOS) runs on top of an L4 microkernel. If anything,
it improves portability: porting Mungi from MIPS to Alpha took
literally few hours of working out endianess-related bugs ;) (tell me
the same about FreeBSD ;P Of course using OSF1 PALcode simplifies life
for FreeBSD, but it's really not an option for our OS research.

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> On Sun, Feb 20, 2000 at 01:48:49PM +1100, Patryk Zadarnowski wrote:
> > > It looks like the hardware has to implement GPTs and know how to
> > > walk them. How can FreeBSD use them without hardware support ?
> > 
> > No it doesn't. We've got software GPT implementations for both MIPS64 and
> > Alpha, and they're both peform very well in our somewhat hostile SASOS
> > conditions.  I'm not sure why you think that a hardware walk is necessary:
> 
> For performance reasons and memory efficiency reasons. My understanding of 

We must be careful here. Although you're getting a samll immediate performance
gain by not flushing the pipelines, the performance is killed if the working
set is larger than the TLB (as it usually is on a moderately-loaded system,
especially in presence of heavy IPC (eg. UNIX pipes)), in which case a smarter
data structure will usually increase the TLB coverage.

And don't forget that with VHPT you'll be getting nested TLB faults quite
frequently in a sparsely-populated page table (think shared libraries).

Efficiency-wise, Kevin has shown that you only need a fairly small VPHT, and
it is global, so you ammortise the cost across all running tasks.  Further,
you can easily share a GPT or LPCtrie subtrees, at which stage the whole
memory-wastage argument goes completely out of the window (I'm currently
writing a microkernel that is intended to demonstrate just that on UltraSPARC
which has an MMU vaguely resembling that of IA-64.). Besides, doesn't Linux
duplicate the structure anyway even when it uses a hardware-walked page table?

Avoiding data duplication isn't always a good thing:
as a rule, caching helps. ;)

> your proposal is - use VHPT as a large in memory TLB and use GPT as
> operating system's primary page table.

Precisely.

> Doesn't that involve duplication of information in memory, especially if the
> hash table is big ?

No, not significantly, for two reasons: first, you don't need a huge VPHT --
512KB is more than enough. Also, VPHT becomes a cache for the actual page
table. It's been empirically demonstrated that 64 bit (esp. sparse 64 bit)
page tables really need such a cache (software TLB) anyway. And it's the main
way Intel planned VPHT to be used in the first place. The performance
improvement tends to be significant (look at Kevin's PhD that I've posed
before.)  Besides, the amount of space saved due to a smarter page table data
structure more than compensates for the additional memory anyway.

> > the only reason why IA-64 walks VPHT in hardware *at all* is to minimize
> > the impact on the pipeline and improve ILP:
> 
> I think that's an important reason. A software only TLB miss handler
> would be inferior to a VHPT based solution on IA-64, IMO.

It's the only justification Rumi Zahir (head of the IA-64 team) gave me when I
was complaining about it.  (as in: ``why bother? 64 bit page tables are an
open problem and no other 64 bit platform I know of provides a hardware page
table walk''. BTW, does anoone know if HP-PA and IBM 64bit PPC implement a
hardware PT walk?

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> On Sun, Feb 20, 2000 at 12:42:14PM +1100, Patryk Zadarnowski wrote:
> > One more thing about GPTs (I thought I'll leave that till last. ;)
> > Jochen Liedtke holds a German patent on them, although he will
> > probably be fairly easily convinced to give FreeBSD rights to use
> > them. I'll be happy to ask (if we're interested.)
> 
> It looks like the hardware has to implement GPTs and know how to
> walk them. How can FreeBSD use them without hardware support ?

No it doesn't. We've got software GPT implementations for both MIPS64 and
Alpha, and they're both peform very well in our somewhat hostile SASOS
conditions.  I'm not sure why you think that a hardware walk is necessary: the
only reason why IA-64 walks VPHT in hardware *at all* is to minimize the
impact on the pipeline and improve ILP: remember that the IA-64 hardware walk
is *advisory* -- that is, the OS still must supply software TLB refill
handlers, even if it uses a linear page table. Specifically, even though the
simulator may not display that behaviour, Itanium aborts the VPHT walk early
in quite a few cornel cases, even if completing the walk would avoid a TLB
miss.

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> :Kevin Elphinstone did a PhD thesis on TLB structures for 64 bit address spaces
> :and it turns out that hash tables perform quite poorly. I'd suggest GPTs
> :instead, or maybe LPCtrie that Chris Szmajda has been working on here at UNSW.
> :Both have the advantage of supporting multiple page sizes that IA64 (and
> :Alpha) offer, and hence dramatically increasing the TLB coverage over what
> :Linux (or any other commercial OS that took a bite at IA64) can achieve.
> :Kevin's paper's at:
> :ftp://ftp.cse.unsw.edu.au/pub/users/disy/papers/Elphinstone:phd.ps.gz
> :
> :Maybe that way we can somehow make use of the Itanium's 4GB page size ;
> :
> :Pat.
> 
> Linux has a good idea re: mapping all of real memory into KVM, it's
> just one that doesn't work well on a 32 bit architecture :-).  But on
> a 64 bit architecture it can be seriously useful.  At the very least
> we can get rid of the private pmap pages and make pmap copying a much
> faster operation.

Actually, on IA64 this is not needed at all. The thing is, we've got
eight regions accessible simultaneously (sort of like MIPS address
space regions, only fully configurable, with per-region page table),
so we can always reserve region 0 for user space, 1 for shared
libraries, 2 for physical memory and 3 for KVM, and maybe even disable
the page table for region 2, and use Keys to grant physical memory
access permissions on demand. That way we don't waste TLB (umm... TC)
entries for essentially one-to-one mappings.

> I read Kevin's thesis.  Facinating!  The GPT concept is essentially

What is even more fascinating about IA-64 that the software TLB that
Kevin describes in his thesis can be walked in hardware, and hence can
cache variable page sizes (although unfortunately not all the IA-64
pages sizes are supported by VPHT) The only other architecture that
offers that is SPARC, but their software TLB supports only 4KB and
64KB page sizes, so all other pages must be reloaded directly from the
page table.

> a radix tree (and a degenerate version of the radix tree is, of course,
> the normal two-level page table IA32 uses).  All the memory and
> performance issues Kevin brings up are exactly the same memory and
> performance issues that a radix tree has.   And he is bang-on in 
> regards to node sharing.  With a normal page table node sharing is

What's funny is that nobody (to the best of my knowledge) had the guts
to implement node sharing or even variable page sizes in GPTs. They're
a nightmare to code. Did I mention that we've been using them on MIPS
and Alphas for few years now in our research SASOS? (and a few months
on StrongARM, and soon on SPARCs ;) So they are field tested, and not
just some piece of benchmark-based theorising.

> difficult because each page in the page table represents a large area
> of memory (4MB on IA32).  But using a GPT we can potentially node-share
> the bulk of the pages associated with shared libraries despite there
> being COW'd pages in the middle of that space from the dynamic linking.

LPCtires look even better. Have a look at

http://www.cse.unsw.EDU.AU/~cls/cls.thesis.ps.gz

they're designed *specifically* to promote variable pages sizes, and
Chris claims that adding node sharing to his current implementation
(he's got an almost-generic one that works on MIPS 4K, all Alphas and
theoretically SPARCs) would be trivial.

One more thing about GPTs (I thought I'll leave that till last. ;)
Jochen Liedtke holds a German patent on them, although he will
probably be fairly easily convinced to give FreeBSD rights to use
them. I'll be happy to ask (if we're interested.)

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> :...
> :and Linux essentially treats hardware page tables as TLBs.
> :
> :The problem with the above approach is duplication of information between
> :Linux page tables and hardware page tables and inefficient use of memory
> :for page tables.
> :
> :I think OSes like FreeBSD which don't have a concept of machine independent
> :page table are essentially free to do anything in the hat layer and thus 
> :have more flexibility.
> 
> If I understand the hardware hash table method correctly, then
> I think the absolute best choice for FreeBSD is to use that method
> as it will allow us to get rid of the scaleability problems we have
> with the pv_entry_t scheme we use for IA32.  The number of pv_entry_t's
> in an IA64 architecture wind up being fixed.  How big can we make the 
> hardware-assisted hash table?
> 
> Also, a hash table scheme is a much better fit for a 64 bit address
> space model, especially with sparse mappings.  The MIPS R4K and later
> all use a hash table scheme and it seems to work well for them.

Kevin Elphinstone did a PhD thesis on TLB structures for 64 bit address spaces
and it turns out that hash tables perform quite poorly. I'd suggest GPTs
instead, or maybe LPCtrie that Chris Szmajda has been working on here at UNSW.
Both have the advantage of supporting multiple page sizes that IA64 (and
Alpha) offer, and hence dramatically increasing the TLB coverage over what
Linux (or any other commercial OS that took a bite at IA64) can achieve.
Kevin's paper's at:
ftp://ftp.cse.unsw.edu.au/pub/users/disy/papers/Elphinstone:phd.ps.gz

Maybe that way we can somehow make use of the Itanium's 4GB page size ;

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> > You're being just plain silly.  It takes about 5 minutes with the
> > manuals to realize just how little AXP and IA-64 have in common: one
> > is a classic superscalar out-of-order design, the other is just about
> > the opposite: a typical explicit-ILP architecture. What makes IA-64
> > great is the 8 years of statistical analysis of real-life software the
> > architecture design team spent fine-tuning the instruction set. What
> > makes AXP great is the clock rates Digital/Compaq manages to pump into
> > the beasts ;)
> 
> What makes IA-64 great is the fact that it has not been deployed, so
> Intel can say whatever it pleases them.
> 
> If you got REAL LIFE NUMBERS, based on REAL LIFE PERFORMANCE, then we
> can talk. Let's see how it does Quake, then we can talk.

This is rapidly becoming a stupid flame war so in the interest of keeping the
list on-topic, I won't be replying publically to this thread from now on. ;)

I *do* have some performance figures, as Intel has had the silicon for over
six months now, but, of course, Intel being Intel, their lawyers keep
everything under a wrap for now.

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> 
> > What can one say to that, apart from "I have one right here and it works 
> > just fine" - not something you can say about the IA-64. 8)
> 
> I'll just reach down and pat my trusty pair of manufactured-in-1993 Alpha
> 3000's on their heads...  :)
> 
> Oh, forgot...  It's not new until Intel does it...  sorry...
> 
> mike

You're being just plain silly.  It takes about 5 minutes with the
manuals to realize just how little AXP and IA-64 have in common: one
is a classic superscalar out-of-order design, the other is just about
the opposite: a typical explicit-ILP architecture. What makes IA-64
great is the 8 years of statistical analysis of real-life software the
architecture design team spent fine-tuning the instruction set. What
makes AXP great is the clock rates Digital/Compaq manages to pump into
the beasts ;)

And no, there's nothing fundamentally new in IA-64 apart from the fact
that they're the last kids on the block with a 64 bit chip ;)

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> "I could have had a PA-8600!"?  Today, and not at some vague point in the
> future?

That sort-of misses the point, as I'm taking a research OS perspective, where
IA-64 is trully unique in terms of versitality and a well thought-through
design (especially when it comes to SASOS support!) Besides, that point in the
future is not all that vague at all ;)

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> > > > Which leads to my potentially ignorant question: Where is FreeBSD
> > > > w/regards to running on the Itanium (or other 64bit chips)?
> > >
> > > Waiting for somebody at Intel to give us either hardware or simulator
> > > time.  Without either of those things, "working on" Itanium support
> > > is a pretty pointless exercise.
> >
> > Just a thought:
> >
> > One could use the released 64-bit Itanium gcc, create a i386->itanium
> > crosscompiler, and start preparing some stuff?
> > Marco van de Voort ([EMAIL PROTECTED])
> > 
> >
> 
> The difficult bits rarely have anything to do with compilers and such
> (especially given that most of the code has been through a 64-bit port to
> the alpha).  The system-mode pieces of IA-64/Merced were not public until
> recently; I noticed the full document set just became available on the intel
> web site this week. There's also the Linux port that was posted to the web
> in the past week or two; that should show what's needed for a FreeBSD port.

The Linux port is extremely minimalistic and uses the minimum amout of IA-64
features to get the OS to do anything useful.

> Of course, as was mentioned before, without hardware or a simulator it's
> pretty pointless to put much effort into something like this.

Also, you'll find that the actual silicon is somewhat different from the
documentation: whole chunks of the architecture are either unimplemented or
covered by errata, and not planned to be fixed in the public Itanium
silicon. The OS teams that signed NDAs with Intel (including the Linux team:
most of their code has been written by IA-64 teams at Intel and HP) have been
cooperating very closely with Intel and were given a lot of information that
(most of us) can only dream about. That is to say: even the simulator wouldn't
help much right now.

On the other hand, IA-64 is a very exotic architecture from the OS's point of
view, and anyone planning to port *BSD to it should probably start planning
ASAP.

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> Patryk Zadarnowski wrote:
> > FreeBSD when that happens. In the meantime, the only alternative would be to
> > convince Intel to give someone their IA-64 SimOS, but there's an extermely
> > slim chance of that happening (from talking to someone on the IA-64 team.)
> > 
> 
> An alternative to IA-64 is the alpha processor.  Last time
> I checked, FreeBSD ran just peachy on a 64-bit processor. ;-)
> Check out Cmpaq's test drive program.

I don't know... I'm still to get it to boot on mine (NetBSD runs fine, but for
some bizzare reason, FreeBSD insists on a serial console ;) Anyway, alphas are
boring compared to Itanium. What else can you say about a chip with 3MB of L3
cache on the die, a four clock cycle latency to carry the signal from one end
of the chip to the other, and the main design limitation being the US power
supplies? :) Not to mention the fact that Intel isn't even planning to release
any single-cpu system

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 64bit OS?

[Patryk Zadarnowski]

> 
> Just read this article:
> 
> http://www.zdnet.com/zdnn/stories/news/0,4586,2440002,00.html
> 
> Which leads to my potentially ignorant question: Where is FreeBSD
> w/regards to running on the Itanium (or other 64bit chips)?

Considering the fact that Intel released the IA-64 OS info only on the 15th,
and, to my knowledge, haven't signed any NDA's with anyone from the FreeBSD
team, I'd assume that we're precisely nowhere. ;)

Having said that, I'll be getting Itanium hardware fairly soon after it's
avaliable outside of Intel, and would be ultra-happy to work on an IA-64
FreeBSD when that happens. In the meantime, the only alternative would be to
convince Intel to give someone their IA-64 SimOS, but there's an extermely
slim chance of that happening (from talking to someone on the IA-64 team.)

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD.

[Patryk Zadarnowski]

> Recently I was tasked to find a way to scale up our MYSQL server, running
> MYSQL3.22.15 on FreeBSD3.3.  I've been testing a hardware RAID solution,
> and found that with 6 disks in a RAID5 configuration, the system was only
> perhaps 30% faster than when running on a single disk.  [The 6 disks in the
> RAID5 are the same model as the single-disk test I was comparing against.]
> 
> Experimentation determined that pthreads was the problem.  FreeBSD's
> implementation of pthreads using a select() loop, and select() always says
> that disk I/O is ready to proceed, and disk I/O never return EWOULDBLOCK.
> Essentially, pthreads was serializing the MYSQL read() requests, and if the
> dataset exceeds memory size, performance becomes entirely seek bound.
> 
> I've implemented a rough fix, which is to rfork() processes which I label
> "iothreads" to handle the disk I/O.  The parent process running pthreads
> has a socketpair() to each of the iothreads.  The iothreads wait for
> requests on the socketpair, and since socketpairs can block, pthreads can
> handle them efficiently.  This essentially allows me to turn blocking disk
> I/O calls into non-blocking calls.  Having multiple pending seeks turns out
> to be a huge win for MYSQL, allowing it to scale much better as disks are
> added to the RAID5 array.
> 
> Unfortunately, I'm concerned about using this code in production, because
> it needs a fair amount of cleanup to handle signals and administrative
> functions correctly.  For this reason and others, I'm starting a project to
> move it into the pthreads library itself.  Before I embark on that effort,
> I have a couple questions:
> 
> 1) Does this seem like a reasonable approach?  [It _works_, and well.  But
> it tastes strongly of hack.]
> 
> 2) Does anyone have suggestions for a solution that will be cleaner and
> won't take man-months to implement?  [Which is the redeeming quality of
> what I've got - it took me two days to zero in on a very workable
> solution.]
> 
> 3) Is anyone working on something I might leverage off of in this area?
> [For instance, a select()-based interface to async I/O?  Or support for
> blocking disk I/O in select() and read()?]
> 
> 4) Is there anyone willing to commit to testing my modified pthreads
> library against MYSQL?  [I'll be stress testing it quite heavily, of
> course.  It would probably also be testable against Squid with async I/O
> and multithreaded Apache 2.0.]

I'm no expert on pthreads, but, if you decide to proceed with
implementing a mixed user-land/rfork pthread implementation, may I
suggest that you implement is through POSIX pthread_attr_setscope()
interfaces instead of some local extension. pthread_attr_setscope()
sounds like a portable interface to precisely what you're trying to
achieve.

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [OFFTOPIC] alt. C compiler

[Patryk Zadarnowski]

> Martin Cracauer <[EMAIL PROTECTED]> wrote in list.freebsd-hackers:
>  > You will not be able to use all features of FreeBSD, of course.
>  > Calling functions that take long long arguments doesn't work, these
>  > should be masked out when compiling struct ansi code. It may get
>  > painful quickly, as such basic things like seek() are amoung them.
> 
> ``long long'' is part of the C9x standard (or whatever it is
> called now, I'm not an expert).  If TenDRA (or lcc) supports
> the latest C standard, then there should be no problem.

TenDRA has no problem parsing any of the FreeBSD headers as far as I
know (and supports long long), although, of course, nobody in their
right mind supports the moving target that C9X is (it's C9X that
supports GCC, not the other way around ;)

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [OFFTOPIC] alt. C compiler

[Patryk Zadarnowski]

> On Wed, 5 Jan 2000, Patryk Zadarnowski wrote:
> 
> > > Hi,
> > > 
> > > is there any alternative (non-commercial) C compiler to use, or is gcc the
> > > best?
> > > 
> > > I have just upgraded my system to -current w/egcs 2.95.2 and I have
> > > several problems with it, especially when using optimizations (-O2 and
> > > such)
> > > 
> > > ok I know there's the good old gcc 2.7.2.3 but a good BSD-licensed
> > > compiler would be nice =)
> > 
> > Check out TenDRA in the ports tree. Unfortunately, most ppl tend to
> > use GCC extensions a lot, so you won't be able to replace gcc, but
> > TenDRA certainly is a solid alternative.
> 
> With the understanding that using Tendra just for the kernel will be
> painful, but (if you're determined) doable.  If you want it for building
> world, you better make prior reservations at the local mental health
> clinic, because YOU WILL NEED IT before you get that done.

Certainly, although it's still probably the only trully-free C compiler
around, and definitely the only more-or-less-free ISO C++ compiler.

If anyone is interested, the main TenDRA web site has been down for a
while, so I've set up a mirror at http://siliconbreeze.com/TenDRA/.

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: [OFFTOPIC] alt. C compiler

[Patryk Zadarnowski]

> Hi,
> 
> is there any alternative (non-commercial) C compiler to use, or is gcc the
> best?
> 
> I have just upgraded my system to -current w/egcs 2.95.2 and I have
> several problems with it, especially when using optimizations (-O2 and
> such)
> 
> ok I know there's the good old gcc 2.7.2.3 but a good BSD-licensed
> compiler would be nice =)

Check out TenDRA in the ports tree. Unfortunately, most ppl tend to
use GCC extensions a lot, so you won't be able to replace gcc, but
TenDRA certainly is a solid alternative.

Pat.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Limitations in FreeBSD

[Patryk Zadarnowski]

> In the last episode (Oct 29), Lars Gerhard Kuehl said:
> > > Think about it for a second.  How big is a pointer?
> > 
> > The Intel architecture still supports segmented memory,
> > so the effective maximum pointer size is 48 bit.

The extra 16 bits of the segment don't actually contribute to the
address space size on IA32, as Intel decided to do segment translation before
virtual address translation (ie, all segments have to fit in the same
32bit vaddr space). PPC, on the other hand ;) If you want a trully
gigantic address space, try a 64 bit PPC, it's got 80 bit addresses, even
if they're totally and utterly useless unless you're writing a SASOS.

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: updating packages automatically...

[Patryk Zadarnowski]

> On Sat, 25 Sep 1999, Chris Costello wrote:
> 
> >Aah!  No!  I tried that with GNOME once and it drove me insane
> > for about two weeks.
> > 
> >Auto-upgrades on ports would be _very_ _very_ bad, especially
> > for those using apache from ports!
> 
> that's right. i thought about having some kind of exclude list for ports
> that shall never be upgraded automatically. anyway, the script will just
> generate a shell script output. it should not replace packages without
> manual intervention.

If most FreeBSD  users are like me, you should set  up an include list
instead.  Then, it could actually be sort of useful. Most people would
use it to auto-upgrade packages for beta and other unstable software.

However, I  think that an /etc/periodic/weekly script  that reports on
which packages are outdated in the  weekly report would be a much more
welcome utility ;)

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: "style" question

[Patryk Zadarnowski]

> I'm looking at cleaning up a few compile nits and I'm wondering what the
> officially approved way of silencing "may not be used" warnings:
> 
> int
> foo(int flag)
> {
> int j;
> 
> if (flag) 
> j = 1;
> 
> /* 
>  * This noop statement is enough to confuse the optimiser so it 
>  * forgets that j is initialised iff flag != 0 
>  */
> flag = !!flag; 

I don't know about the "official"  way to silence the compiler (a well
placed  else statement  or a  "default" switch  case usually  does the
trick for  me) That is  to say, I'm  willing to argue that  fixing the
flow  of  control is  the  only  clean way  of  getting  rid of  these
warnings, unless  you know something special about  the allowed values
of  the offending variable  (eg.  you  know that  your switch  case is
exhaustive),  in which case  a dummy  "default" or  initializer cannot
hurt you much.

Also !!x IS NOT  a noop. For example, !!5 == 1.   I think you meant to
say `flag = ~~flag', which indeed is a NOP.

Pat.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: "style" question

[Patryk Zadarnowski]

> I'm looking at cleaning up a few compile nits and I'm wondering what the
> officially approved way of silencing "may not be used" warnings:
> 
> int
> foo(int flag)
> {
> int j;
> 
> if (flag) 
> j = 1;
> 
> /* 
>  * This noop statement is enough to confuse the optimiser so it 
>  * forgets that j is initialised iff flag != 0 
>  */
> flag = !!flag; 

I don't know about the "official"  way to silence the compiler (a well
placed  else statement  or a  "default" switch  case usually  does the
trick for  me) That is  to say, I'm  willing to argue that  fixing the
flow  of  control is  the  only  clean way  of  getting  rid of  these
warnings, unless  you know something special about  the allowed values
of  the offending variable  (eg.  you  know that  your switch  case is
exhaustive),  in which case  a dummy  "default" or  initializer cannot
hurt you much.

Also !!x IS NOT  a noop. For example, !!5 == 1.   I think you meant to
say `flag = ~~flag', which indeed is a NOP.

Pat.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Intel Merced FreeBSD???

[Patryk Zadarnowski]

> On Fri, Aug 27, 1999 at 08:45:31PM -0400, Sergey Babkin wrote:
> > Thomas David Rivers wrote:
> > 
> > >   Microsoft needs a "business quality" version of Windows,
> > >  which it claims is Windows/2000.   That version of Windows
> > >  could benefit from a 64-bit port, if for marketing only; but
> > >  I don't think it would result in the volume of sales Intel
> > >  is looking for.
> > 
> > A funny thing is that Microsoft is porting essentially a
> > 32-bit version of Windows to Merced. All the programs for
> > Windows that want to use 64-bit support will have to be
> > modified because the MS compiler defines both int and long
> > as 32-bit. On the other hand the Unix compilers (at least 
> > UnixWare and as far as I understood that's the common Unix
> > convention) provide a mode with 64-bit longs that gives
> > certain degree of 64-bit awareness just by recompiling.

I'm yet to see  a 64 bit long on a 32 bit  OS. It would be brain-dead,
IMO,  especially as  longs  are typically  assumed  to be  as fast  as
ints.  However, most  Unix  programs are  (should  be?) designed  with
portability  in  mind, and  that  means  making  no assumptions  about
sizeof(long). That's what makes porting  U*ix to 64 bit so much easier
than porting  Wheenbloze  In the later, everyone  thinks that they
know  every petty  detail of  the  architecture, often  down to  exact
values of pointers..

Incidentally, Windows CE has been running  on a 64 bit CPU for quite a
while  (MIPS R4K),  although MIPS  went  out of  its way  to make  R4K
32bit-compatible at least in the userland.

Patryk.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Intel Merced FreeBSD???

[Patryk Zadarnowski]

> On Fri, Aug 27, 1999 at 08:45:31PM -0400, Sergey Babkin wrote:
> > Thomas David Rivers wrote:
> > 
> > >   Microsoft needs a "business quality" version of Windows,
> > >  which it claims is Windows/2000.   That version of Windows
> > >  could benefit from a 64-bit port, if for marketing only; but
> > >  I don't think it would result in the volume of sales Intel
> > >  is looking for.
> > 
> > A funny thing is that Microsoft is porting essentially a
> > 32-bit version of Windows to Merced. All the programs for
> > Windows that want to use 64-bit support will have to be
> > modified because the MS compiler defines both int and long
> > as 32-bit. On the other hand the Unix compilers (at least 
> > UnixWare and as far as I understood that's the common Unix
> > convention) provide a mode with 64-bit longs that gives
> > certain degree of 64-bit awareness just by recompiling.

I'm yet to see  a 64 bit long on a 32 bit  OS. It would be brain-dead,
IMO,  especially as  longs  are typically  assumed  to be  as fast  as
ints.  However, most  Unix  programs are  (should  be?) designed  with
portability  in  mind, and  that  means  making  no assumptions  about
sizeof(long). That's what makes porting  U*ix to 64 bit so much easier
than porting  Wheenbloze  In the later, everyone  thinks that they
know  every petty  detail of  the  architecture, often  down to  exact
values of pointers..

Incidentally, Windows CE has been running  on a 64 bit CPU for quite a
while  (MIPS R4K),  although MIPS  went  out of  its way  to make  R4K
32bit-compatible at least in the userland.

Patryk.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: from number to power of two

[Patryk Zadarnowski]

> Does anyone know an inexpensive algorithm (O(1)) to go from an number to
> the next (lower or higher) power of two.
> 
> 1 -> 1
> 2,3   -> 2
> 4,5,6,7   -> 4
> 8,9,10,11,12,13,14,15 -> 8
> etc.
> 
> So %1101 should become either %1 or %1000.
> 
> The only solution I have so far is a table. That is a possibility as the
> the highest number will be 32 I think.

Nick,

Probably the  best solution I can think  of is a binary  search on the
number. I'd estimate it as better  than a table, as you save on memory
references (tables sound cool, but, from experience, they cause enough
extra   data   cache  misses   to   kill   any   advantage,  even   in
a highly-optimized inner loop.

For 8-bit integets, a quick solution is:

int
round_up(int x)
{
if (x & 0xf0) {
if (x & 0xc0)
return (x & 0x80) ? 0x80 : 0x40;
else {
return (x & 0x20) ? 0x20 : 0x10;
}
}
else {
if (x & 0xc)
return (x & 0x8) ? 0x8 : 0x4;
else {
return (x & 0x2) ? 0x2 : 0x1;
}
}
}

It's actually faster  than the BSF/BSR operations on  Pentium (and the
ffs() libc function),  as Pentium does a sequential  search of the bit
string and therefore is O(n)  (eek!)  

The innermost comparison could probably  be avoided if it wasn't 00:37
or if  I didn't have to  get up early  in the morning. You  could also
combine  that with  a smaller  lookup table  to get  the best  of both
worlds.

Patryk.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: from number to power of two

[Patryk Zadarnowski]

> Does anyone know an inexpensive algorithm (O(1)) to go from an number to
> the next (lower or higher) power of two.
> 
> 1 -> 1
> 2,3   -> 2
> 4,5,6,7   -> 4
> 8,9,10,11,12,13,14,15 -> 8
> etc.
> 
> So %1101 should become either %1 or %1000.
> 
> The only solution I have so far is a table. That is a possibility as the
> the highest number will be 32 I think.

Nick,

Probably the  best solution I can think  of is a binary  search on the
number. I'd estimate it as better  than a table, as you save on memory
references (tables sound cool, but, from experience, they cause enough
extra   data   cache  misses   to   kill   any   advantage,  even   in
a highly-optimized inner loop.

For 8-bit integets, a quick solution is:

int
round_up(int x)
{
if (x & 0xf0) {
if (x & 0xc0)
return (x & 0x80) ? 0x80 : 0x40;
else {
return (x & 0x20) ? 0x20 : 0x10;
}
}
else {
if (x & 0xc)
return (x & 0x8) ? 0x8 : 0x4;
else {
return (x & 0x2) ? 0x2 : 0x1;
}
}
}

It's actually faster  than the BSF/BSR operations on  Pentium (and the
ffs() libc function),  as Pentium does a sequential  search of the bit
string and therefore is O(n)  (eek!)  

The innermost comparison could probably  be avoided if it wasn't 00:37
or if  I didn't have to  get up early  in the morning. You  could also
combine  that with  a smaller  lookup table  to get  the best  of both
worlds.

Patryk.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: quad_t and portability

[Patryk Zadarnowski]

> In message  
> "Brian F. Feldman" writes:
> : You can always use off_t with "%qd", (int64_t)foo.
> 
> But that isn't portbale.  %qd is a bsdism.  %lld and %llu are the
> latest C standards way to say that.

If  you're  that fixed  on  portability, "%lux%08ulx",  (long)foo>>32,
(long)foo  is  always  a  perfectly-portable  option  (or  %lud%08ud",
(unsigned long)foo  / UL,  (unsigned long)foo %  UL if
you insist  on decimal output; you'll  need to watch the  signs if you
want to use longs instead of unsigned longs, but it's only mariginally
more complicated).  I doubt  that the cost  of splitting foo  into two
would  be significant  considering that  it  is split  up into  digits
inside  printf()   anyway  (it  might  actually  be   faster  on  some
architectures).

l8r,
patryk.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: quad_t and portability

[Patryk Zadarnowski]

> In message <[EMAIL PROTECTED]> "Brian F. 
>Feldman" writes:
> : You can always use off_t with "%qd", (int64_t)foo.
> 
> But that isn't portbale.  %qd is a bsdism.  %lld and %llu are the
> latest C standards way to say that.

If  you're  that fixed  on  portability, "%lux%08ulx",  (long)foo>>32,
(long)foo  is  always  a  perfectly-portable  option  (or  %lud%08ud",
(unsigned long)foo  / UL,  (unsigned long)foo %  UL if
you insist  on decimal output; you'll  need to watch the  signs if you
want to use longs instead of unsigned longs, but it's only mariginally
more complicated).  I doubt  that the cost  of splitting foo  into two
would  be significant  considering that  it  is split  up into  digits
inside  printf()   anyway  (it  might  actually  be   faster  on  some
architectures).

l8r,
patryk.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Swap overcommit

[Patryk Zadarnowski]

> At 9:52 PM -0700 7/15/99, Matthew Dillon wrote:
> >:> ...  How many programmers bother to even *clear* errno before
> >:> making these calls (since some system calls do not set errno
> >:
> >:> if it already non-zero).  Virtually nobody.
> >:  ^^^
> >:
> >:Erm... WTF?!?! If so, why the HELL are we doing that?!?
> >
> >No, wait, I got that wrong I think.
> >
> >Oh yah, I remember now.  Hmm.  How odd.  I came across a case
> >where read() could return -1 and not set errno properly if
> >errno was already set, but a perusal of the kernel code seems
> >to indicate that this can't happen.  Very weird.
> 
> For what it's worth, I know I've run into situations where errno
> had to be cleared before calling some system routine (but I don't
> think it was read, and I am sure it wasn't on freebsd).

Ahem, I'm not sure what that's got to do with swap overcommit, but
anything to distract this thread is a good thing ;)

The correct thing to do with errno is to clear it before a call IFF
you are going to check its value on return from the call, simply
because the calls NEVER don't clear errno on success, but set/change
it on error.  Every standard I've seen requires this behaviour quite
explicitely, and I'm preaty sure it's documented someone in BSD man
pages too. It's definitely correct if you look at the syscall stub
code in libc.

And yes, almost all the code I've seen does the right thing when
it comes to handling errno, including checking its value on an error
from system call (ususally by calling warn() or err()), so the
``Virtually nobody'' argument above is rather misguided.

If something in libc READS errno without clearing it (other than
err/warr functions that is ;), it's badly broken and should be fixed
in the library, not in the user code. IMHO.

patryk.



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Swap overcommit

[Patryk Zadarnowski]

> At 9:52 PM -0700 7/15/99, Matthew Dillon wrote:
> >:> ...  How many programmers bother to even *clear* errno before
> >:> making these calls (since some system calls do not set errno
> >:
> >:> if it already non-zero).  Virtually nobody.
> >:  ^^^
> >:
> >:Erm... WTF?!?! If so, why the HELL are we doing that?!?
> >
> >No, wait, I got that wrong I think.
> >
> >Oh yah, I remember now.  Hmm.  How odd.  I came across a case
> >where read() could return -1 and not set errno properly if
> >errno was already set, but a perusal of the kernel code seems
> >to indicate that this can't happen.  Very weird.
> 
> For what it's worth, I know I've run into situations where errno
> had to be cleared before calling some system routine (but I don't
> think it was read, and I am sure it wasn't on freebsd).

Ahem, I'm not sure what that's got to do with swap overcommit, but
anything to distract this thread is a good thing ;)

The correct thing to do with errno is to clear it before a call IFF
you are going to check its value on return from the call, simply
because the calls NEVER don't clear errno on success, but set/change
it on error.  Every standard I've seen requires this behaviour quite
explicitely, and I'm preaty sure it's documented someone in BSD man
pages too. It's definitely correct if you look at the syscall stub
code in libc.

And yes, almost all the code I've seen does the right thing when
it comes to handling errno, including checking its value on an error
from system call (ususally by calling warn() or err()), so the
``Virtually nobody'' argument above is rather misguided.

If something in libc READS errno without clearing it (other than
err/warr functions that is ;), it's badly broken and should be fixed
in the library, not in the user code. IMHO.

patryk.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Bursting at the seams (was: Heh heh, humorous lockup)

[Patryk Zadarnowski]

> jul...@whistle.com (Julian Elischer) writes:
> 
> > we already use the gs register for SMP now..
> > what about the fs register?
> > I vaguely remember that the different segments could be used to achieve
> > this (%fs points to user space or something)
> 
> You can't extend the address space that way, segments are all parts of
> the single 4GB address space described by the page mapping.

True, but you can reserve a part of the 4GB address space (say 128MB of it)
for partitioning into tiny (say 8MB) address spaces (which are still flat,
just small), for use by small processes, the idea being that all those small
processes will than share a single page table without compromising on memory
protection (the GDT is under full OS's control anyway), or the simplicity of
a flat address space (virtual addresses still start at 0 and continue till
the top of address space; the scheme is totally transparent.)

patryk.



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Bursting at the seams (was: Heh heh, humorous lockup)

[Patryk Zadarnowski]

> [EMAIL PROTECTED] (Julian Elischer) writes:
> 
> > we already use the gs register for SMP now..
> > what about the fs register?
> > I vaguely remember that the different segments could be used to achieve
> > this (%fs points to user space or something)
> 
> You can't extend the address space that way, segments are all parts of
> the single 4GB address space described by the page mapping.

True, but you can reserve a part of the 4GB address space (say 128MB of it)
for partitioning into tiny (say 8MB) address spaces (which are still flat,
just small), for use by small processes, the idea being that all those small
processes will than share a single page table without compromising on memory
protection (the GDT is under full OS's control anyway), or the simplicity of
a flat address space (virtual addresses still start at 0 and continue till
the top of address space; the scheme is totally transparent.)

patryk.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Bursting at the seams (was: Heh heh, humorous lockup)

[Patryk Zadarnowski]

> we already use the gs register for SMP now..
> what about the fs register?
> I vaguely remember that the different segments could be used to achieve
> this (%fs points to user space or something)

... as I've suggested a few days ago, and was told to shut up with a (rather
irrelevant) reference to SASOS's. It can be done, in fact, it's already been
done, with 50%+ performance improvement for tasks that rely heavily on IPC.
(think client/server; email me for references.) However, it would involve a
rather major redesign of the MMU and some redesign of the syscall stack.
Further, one ends up restricting the size of the address space, which is fine
until you start loading dynamic libraries. With something like libc, the
working set may be small if all you need is a few system call stubs, but you
end up with an extremely sparse address space which cannot be handled well
with segmentation.

Incidentally, you don't need to use FS to implement a tagged TLB using
Liedtke's small address spaces. All you need is to modify CS, DS and SS;
noone in the unix world relies on the values of ES and FS anyway; if they do,
a quick-and-easy segmentation fault will teach them a lesson preaty fast. ;)

patryk.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: Bursting at the seams (was: Heh heh, humorous lockup)

[Patryk Zadarnowski]

> Why not put the kernel in a different address space?  IIRC there's no
> absolute requirement for the kernel and userland to be in the same
> address space, and that way we would have 4 GB for each.

Wouldn't that make system calls that need to share data between kernel
and user  spaces hopelessly  inefficient?  Things like  sysctl() would
need to introduce (temporary)  memory mappings, and someone would have
to keep  track of these mappings  and remove them as  required, or the
kernel would probably run out of  address space in no time, given even
with 4GB to spare. On  top of that, every mapping established requires
some  messing arround with  the TLB,  which, at  least on  pentium, is
rather expensive.

Incidentally,  someone already experimented  with such  "dual" address
spaces on Linux, and  the result was a 30% or so  slow down. If you're
interested, I can  give you the relevant references  (the scenario was
somewhat  different, but  the source  of the  performance hit  was the
"dual" address space.)

patryk.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: support for i386 hardware debug watch points

[Patryk Zadarnowski]

> I've got some prototype code in place which supports the context
> switching part of this.  It's pretty simple right now, as I'm trying
> to keep changes to a minimum.
> 
> What I've done is simply added the dr0-dr3,dr6,dr7 registers to
> 'struct pcb' in /usr/src/sys/i386/include/pcb.h.  In cpu_switch(),
> during a save operation, I load %dr7, and check the lower 8 bits,
> which indicate if any breakpoints are in use.  If they are, I save all
> the debug registers, then clear out %dr7, which disables the
> breakpoints.  During a restore operation, I load the value of %dr7
> from the pcb structure of the new process, and if any of the lower 8
> bits are set, I restore all the debug registers.
> 
> This is not as efficent as it could be implemented with a separate
> flag to indicate whether saving the debug registers is necessary since
> loading/storing the debug registers is fairly expensive (11 clocks on
> an i486).

22 clocks on i386, 10 on i486, 11 on pentium. Also, on another topic, DRs are
fairly portable as they've been a part of IA32 since i386.

> Comments?

I'm no expert on FreeBSD kernels, but I can speak for L4, and it's
always good to look at past experiences in the area. (L4 is a very
lean microkernel running on x86's, MIPS, (and soon Alphas and ARMs,
although I'm currently in a process of convincing the authors of the
later two to use BSD lincence instead of GPL ;) It currently claims
to have the fastest IPC and lightweight thread implementation, so I
guess it's a good raw model.

Re: support for i386 hardware debug watch points

[Patryk Zadarnowski]

> I've got some prototype code in place which supports the context
> switching part of this.  It's pretty simple right now, as I'm trying
> to keep changes to a minimum.
> 
> What I've done is simply added the dr0-dr3,dr6,dr7 registers to
> 'struct pcb' in /usr/src/sys/i386/include/pcb.h.  In cpu_switch(),
> during a save operation, I load %dr7, and check the lower 8 bits,
> which indicate if any breakpoints are in use.  If they are, I save all
> the debug registers, then clear out %dr7, which disables the
> breakpoints.  During a restore operation, I load the value of %dr7
> from the pcb structure of the new process, and if any of the lower 8
> bits are set, I restore all the debug registers.
> 
> This is not as efficent as it could be implemented with a separate
> flag to indicate whether saving the debug registers is necessary since
> loading/storing the debug registers is fairly expensive (11 clocks on
> an i486).

22 clocks on i386, 10 on i486, 11 on pentium. Also, on another topic, DRs are
fairly portable as they've been a part of IA32 since i386.

> Comments?

I'm no expert on FreeBSD kernels, but I can speak for L4, and it's
always good to look at past experiences in the area. (L4 is a very
lean microkernel running on x86's, MIPS, (and soon Alphas and ARMs,
although I'm currently in a process of convincing the authors of the
later two to use BSD lincence instead of GPL ;) It currently claims
to have the fastest IPC and lightweight thread implementation, so I
guess it's a good raw model.

>From Jochen Liedtke's L4/x86 Reference Manual:

 User-level debug registers exist per thread. DR0..3, DR6 and DR7
 can be accessed by the machine instructions MOV DRx,n and MOV
 r,DRx. However, only task-local breakpoints can be activated,
 i.e. bits L0...3 in DR7 cannot be set. Breakpoints operate per
 thread.  Breakpoints are signalled as #DB exception (INT 1).

 Note that user-level breakpoints are suspended when kernel
 breakpoints are set by the kernel debugger.

This says it all in terms of the user interface (which I think is
brilliant in that it doesn't introduce any ugly new system calls.)

Anyway, the MOV instructions are simulated in sofware, which should be
easy enough. When a MOV DRx, n instruction is executed, it sets a bit
in the TCB (well, it would be a PCB on FreeBSD ;) telling the
scheduler that the DR registers are now valid (and hence should be
saved/restored on a context switch from/to that process.)

While on the topic of L4, would there be any interest in implementing
Liedtke's small address spaces in FreeBSD? Basically, the idea is to
improve TLB utilisation by simulated a tagged TLB on x86 using x86's
segment registers. Because a typical process does not need the full
4GB address space, multiple processes could be multiplexed into a
preallocated portion of the 4GB address space, eliminating the need
for TLB flushes and CR0 reloads when switching between small processes
(which hopefully constitute the bulk of the system load.) As a rough
guide as to what's up for grabs, Liedtke's measured a reduction of the
cost of a context switch on L4 from somewhere between 95 and 914 clocks
(on pentium) down to 23 clock cycles when using small address spaces.
The performance improvement is huge on pentiums, 6x86s and pentiums
II, although the task is far from trivial (read: major changes to the
memory manager and dynamic libraries.)

Oh, if someone's interested, the original paper is at 

http://i30www.ira.uka.de/publications/pubcat/As-pent.ps

And no, I don't voluneer to do it all by myself, although I'd be glad
to help, coordinate the project, or even do most of the work myself
given enough time.

Patryk.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: environment strings

[Patryk Zadarnowski]

> I know about envp.
> 
> What I want to know is the exact position of these variables on the stack.
> 
> and if anywhere I can find some data, on the exact compisoition of the
> stcak, then it will be very helpful.
> 
> references of books and websites wil be most helpful.

Basically, i386 BSD kernels (you're after i386, aren't you?) point ESP to
the following "struct" (which means that it will be dumped at the very
top of the address space)

struct kframe {
int   argc; /* "argc" to be passed to main() */
char *argv[argc];   /* "argv" to be passed to main() */
char *null; /* a NULL pointer terminating argv[] */
char **envp;/* value to be assigned to "environ" */
};
 
/usr/src/lib/csu/i386/crt0.c is probably the best reference you can get
your hands on ;)

Patryk.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: environment strings

[Patryk Zadarnowski]

> I know about envp.
> 
> What I want to know is the exact position of these variables on the stack.
> 
> and if anywhere I can find some data, on the exact compisoition of the
> stcak, then it will be very helpful.
> 
> references of books and websites wil be most helpful.

Basically, i386 BSD kernels (you're after i386, aren't you?) point ESP to
the following "struct" (which means that it will be dumped at the very
top of the address space)

struct kframe {
int   argc; /* "argc" to be passed to main() */
char *argv[argc];   /* "argv" to be passed to main() */
char *null; /* a NULL pointer terminating argv[] */
char **envp;/* value to be assigned to "environ" */
};
 
/usr/src/lib/csu/i386/crt0.c is probably the best reference you can get
your hands on ;)

Patryk.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: environment strings

[Patryk Zadarnowski]

> > This is of course correct except for the `undocumented' claim. The
> > `envp' has been documented as the third argument to main() since the
> > Pharaons (well, not quite ;). Apparently AT&T UNIX even has a
> > (documented) five-parameter main().
> 
> This is news to me.  Can you point to the documentation?

I'll sniff around and get back to you (read: I'll ask our local guru on
PDP-11's and other ancient rituals, who told me about those in the first
place.)

l8r,
patryk.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: environment strings

[Patryk Zadarnowski]

> > I wanted t know where the environment strings i bsd were stored after a
> > program execs another one. 

extern char **environ;

> At the top of memory.  You can access them by the standard (but
> undocumented) method:
> 
> int main (int argc, char *argv [], char *envp [])
> 
> envp is a pointer to the environment strings.  This is true for every
> version of UNIX I know.

This is of course correct except for the `undocumented' claim. The `envp' has
been documented as the third argument to main() since the Pharaons (well, not
quite ;). Apparently AT&T UNIX even has a (documented) five-parameter main().

Besides, the `envp' argument is a recommended extension in ISO/ANSI C, so you
can hardly say that it's undocumented.

l8r,
patryk.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message