From jre@radio Mon Mar 27 17:27:50 1995 Date: Mon, 27 Mar 1995 17:30:02 -0800 From: jre@radio (Joe E.) To: psarc@radio Subject: fast-track processor_info(2) for PowerPC PSARC/1995/077 Cc: powerpc@mtns Content-Length: 1543 I'm sponsoring my own fast track described below. The timer expires on 4/3/95 at 18:00 PST. If not explicitly derailed by that time, it'll be considered approved. Background: The system call processor_info(2), provided since Solaris 2.1 or 2.2, fills in the processor_info_t structure with the processor type and the FPU type. See PSARC/1992/016, which classified these interfaces as Public. That case specified the values for Sparc as "sparc" for both the processor type and FPU type (if an FPU exists), and for x86, as "i386" or "i486" for the processor type and "i387" for the FPU. On x86, we currently only set the processor type to "i386" (never "i486" or "pentium." Proposal: This fast-track specifies what we put in those fields for PowerPC and future ISAs. Basically, it says we follow the pattern and put the ISA name (as returned by "uname -p" on all future architectures, and "ppc" for the PowerPC. This also proposes that the current value of "i386" on all x86 platforms remain. Discussion: Some people have suggested returning more information such as "PowerPC,604", or (on SPARC), the manufacturer and model of the CPU chip. We could, but I don't see any good reason to do this. That information can be obtained (albiet a bit more awkwardly) from the prtconf command, uname -i, or /dev/openprom driver. It seems better to keep the information available from processor_info(2) as simple as possible. Currently, I'm unaware of any programs using this information, except for psrinfo -v. Thanks, Joe E. From markk@sagredo.West.Sun.COM Mon Mar 27 18:26:58 1995 Date: Mon, 27 Mar 1995 18:24:37 -0800 From: markk@sagredo.West.Sun.COM (Mark K.) To: psarc@radio.Eng.Sun.COM, Joe.E.@Eng Subject: Re: fast-track processor_info(2) for PowerPC PSARC/1995/077 Cc: powerpc@mtns.Eng.Sun.COM Content-Length: 718 Clearly there is a lot to be said for returning simple information to people who were probably going to use it for simple things ... but what if someone wanted to do something clever? Supposing I have written some app that I know will run 80% faster if I am a 486 that has decent compare and swap instructions, and so I want to figure out what kind of processor I am on and do the smart thing (switching routine pointers, execing a different load module or what ever other sleazy hack that will double my performance). How do you recommend that my app figure out what processor I am on? do a system("prtconf -v") and process all the output, searching for a processor type property? That sounds extremely expensive. From jre@radio Tue Mar 28 13:14:50 1995 Date: Tue, 28 Mar 1995 13:16:58 -0800 From: jre@radio (Joe E.) To: psarc@radio.Eng.Sun.COM, markk@sagredo.West.Sun.COM Subject: Re: fast-track processor_info(2) for PowerPC PSARC/1995/077 Cc: powerpc@mtns.Eng.Sun.COM, tpm@radio Content-Length: 2097 > From markk@sagredo.West.Sun.COM Mon Mar 27 18:29 PST 1995 > From: markk@sagredo.West.Sun.COM (Mark K.) > To: psarc@radio.Eng.Sun.COM, Joe.E.@Eng > Subject: Re: fast-track processor_info(2) for PowerPC PSARC/1995/077 > Cc: powerpc@mtns.Eng.Sun.COM > X-Sun-Charset: US-ASCII > > Clearly there is a lot to be said for returning simple information > to people who were probably going to use it for simple things ... but > what if someone wanted to do something clever? > > Supposing I have written some app that I know will run 80% faster if > I am a 486 that has decent compare and swap instructions, and so I > want to figure out what kind of processor I am on and do the smart > thing (switching routine pointers, execing a different load module > or what ever other sleazy hack that will double my performance). > > How do you recommend that my app figure out what processor I am on? > do a system("prtconf -v") and process all the output, searching for > a processor type property? That sounds extremely expensive. I'm interested in hearing what others say about this. Maybe you're right. Is there a real need for this? If so, the question is: What is the right interface to get detailed knowledge about the processor type? Is it processor_info(2), or utsname(2), or systeminfo(2)? Do we want to allow different processors to co-exist on an MP? If so, the right interface might indeed be processor_info(2). I only open this up because I have to make a choice for PowerPC. If I follow the existing pattern, is that OK? However, if there's consensus that we should return the precise CPU type (including manufacturer and model on SPARC or whatever), then we can file an RFE for that. I'm less interested in providing that as part of this project, because that isn't my focus at this point, and because I think programs shouldn't depend on exactly what they run on. Can we take the idea of expanding the information provided by processor_info as a separate (future) RFE, and approve the proposed implementation as merely following the existing practice? Thanks, Joe From Howard.A.@Central Tue Mar 28 13:30:18 1995 Date: Tue, 28 Mar 1995 14:27:16 -0700 From: Howard.A.@Central (Howard A.) To: psarc@radio.Eng.Sun.COM, markk@sagredo.West.Sun.COM, Joe.E.@Eng Subject: Re: fast-track processor_info(2) for PowerPC PSARC/1995/077 Cc: powerpc@mtns.Eng.Sun.COM, tpm@radio.Eng.Sun.COM Content-Length: 2876 For what it's worth, in the past I've wanted what amounts to an API to prtconf. Actually, what I think I really wanted was an API to the devinfo tree. This would let me get as much detail or as little detail as I want. Since the interfaces to this part of the system are so inadequatly designed, there are lots of hacks that we'd be better off without. Howard. > From Joe.E.@Eng Tue Mar 28 14:15:02 1995 > Date: Tue, 28 Mar 1995 13:16:58 -0800 > From: Joe.E.@Eng (Joe E.) > To: psarc@radio.Eng.Sun.COM, markk@sagredo.West.Sun.COM > Subject: Re: fast-track processor_info(2) for PowerPC PSARC/1995/077 > Cc: powerpc@mtns.Eng.Sun.COM, tpm@radio.Eng.Sun.COM > > > > From markk@sagredo.West.Sun.COM Mon Mar 27 18:29 PST 1995 > > From: markk@sagredo.West.Sun.COM (Mark K.) > > To: psarc@radio.Eng.Sun.COM, Joe.E.@Eng > > Subject: Re: fast-track processor_info(2) for PowerPC PSARC/1995/077 > > Cc: powerpc@mtns.Eng.Sun.COM > > X-Sun-Charset: US-ASCII > > > > Clearly there is a lot to be said for returning simple information > > to people who were probably going to use it for simple things ... but > > what if someone wanted to do something clever? > > > > Supposing I have written some app that I know will run 80% faster if > > I am a 486 that has decent compare and swap instructions, and so I > > want to figure out what kind of processor I am on and do the smart > > thing (switching routine pointers, execing a different load module > > or what ever other sleazy hack that will double my performance). > > > > How do you recommend that my app figure out what processor I am on? > > do a system("prtconf -v") and process all the output, searching for > > a processor type property? That sounds extremely expensive. > > I'm interested in hearing what others say about this. > > Maybe you're right. Is there a real need for this? If so, the > question is: What is the right interface to get detailed knowledge > about the processor type? Is it processor_info(2), or utsname(2), or > systeminfo(2)? Do we want to allow different processors to co-exist on > an MP? If so, the right interface might indeed be processor_info(2). > > I only open this up because I have to make a choice for PowerPC. > If I follow the existing pattern, is that OK? > > However, if there's consensus that we should return the precise CPU > type (including manufacturer and model on SPARC or whatever), then we > can file an RFE for that. I'm less interested in providing that as > part of this project, because that isn't my focus at this point, and > because I think programs shouldn't depend on exactly what they run on. > > Can we take the idea of expanding the information provided by > processor_info as a separate (future) RFE, and approve the proposed > implementation as merely following the existing practice? > > Thanks, > Joe > > From markk@sagredo.West.Sun.COM Tue Mar 28 13:58:26 1995 Date: Tue, 28 Mar 1995 13:56:07 -0800 From: markk@sagredo.West.Sun.COM (Mark K.) To: psarc@radio.Eng.Sun.COM, Joe.E.@Eng Subject: Re: fast-track processor_info(2) for PowerPC PSARC/1995/077 Cc: powerpc@mtns.Eng.Sun.COM, tpm@radio.Eng.Sun.COM Content-Length: 1914 > From Joe.E.@Eng Tue Mar 28 13:14 PST 1995 > I'm interested in hearing what others say about this. Perhaps ISV input would be helpful here? Do other members of the PPC consortium have opinions? > If so, the > question is: What is the right interface to get detailed knowledge > about the processor type? Is it processor_info(2), or utsname(2), or > systeminfo(2)? Do we want to allow different processors to co-exist on > an MP? If so, the right interface might indeed be processor_info(2). MP does indeed introduce some strange problems. We currently have no means of binding an executable to processors of a particular level. What would we return for a 386 with a four-way pentium up its sleeve? Is detailed information meaningful unless you can force yourself to fun on specific processors? An app that has decided to exploit the Pentium it just found out about might SIGILL if it happened to get dispatched on a lesser processor. > I only open this up because I have to make a choice for PowerPC. > If I follow the existing pattern, is that OK? It may be the case that using any value other than the Lowest Common Denominator ISA unleashes all sorts of terrible problems, and so absent a specific demand for detailed processor information, your proposal is exactly the right thing to do. I don't have a strong assertion that we must return detailed processor information, but I think the question should be explored a bit further before we legislate processor-exploiting apps out of existance. > Can we take the idea of expanding the information provided by > processor_info as a separate (future) RFE, and approve the proposed > implementation as merely following the existing practice? Clearly adopting your convention could not break any existing x86 applications, since they have all been getting i386 anyway. Could any SPARC apps be broken by limiting the specificity of ISA values? From craigr@squaw-valley Tue Mar 28 13:37:54 1995 Date: Tue, 28 Mar 1995 13:37:02 -0800 From: craigr@squaw-valley (Craig Rolandelli) To: psarc@radio.Eng.Sun.COM, markk@sagredo.West.Sun.COM, Joe.E.@Eng, Howard.A.@Central Subject: Re: fast-track processor_info(2) for PowerPC PSARC/1995/077 Cc: powerpc@mtns.Eng.Sun.COM, tpm@radio.Eng.Sun.COM Content-Length: 416 > > For what it's worth, in the past I've wanted what amounts to > an API to prtconf. Actually, what I think I really wanted was > an API to the devinfo tree. This would let me get as much > detail or as little detail as I want. Since the interfaces > to this part of the system are so inadequatly designed, there > are lots of hacks that we'd be better off without. > See bug 1079315. Craig From jre@radio Tue Mar 28 14:04:42 1995 Date: Tue, 28 Mar 1995 14:06:49 -0800 From: jre@radio (Joe E.) To: psarc@radio.Eng.Sun.COM, markk@sagredo.West.Sun.COM Subject: Re: fast-track processor_info(2) for PowerPC PSARC/1995/077 Cc: powerpc@mtns.Eng.Sun.COM, tpm@radio.Eng.Sun.COM Content-Length: 2488 > From markk@sagredo.West.Sun.COM Tue Mar 28 14:00 PST 1995 > From: markk@sagredo.West.Sun.COM (Mark K.) > To: psarc@radio.Eng.Sun.COM, Joe.E.@Eng > Subject: Re: fast-track processor_info(2) for PowerPC PSARC/1995/077 > Cc: powerpc@mtns.Eng.Sun.COM, tpm@radio.Eng.Sun.COM > X-Sun-Charset: US-ASCII > > > > From Joe.E.@Eng Tue Mar 28 13:14 PST 1995 > > > I'm interested in hearing what others say about this. > > Perhaps ISV input would be helpful here? > Do other members of the PPC consortium have opinions? > > > If so, the > > question is: What is the right interface to get detailed knowledge > > about the processor type? Is it processor_info(2), or utsname(2), or > > systeminfo(2)? Do we want to allow different processors to co-exist on > > an MP? If so, the right interface might indeed be processor_info(2). > > MP does indeed introduce some strange problems. We currently have > no means of binding an executable to processors of a particular level. > What would we return for a 386 with a four-way pentium up its sleeve? > Is detailed information meaningful unless you can force yourself to > fun on specific processors? An app that has decided to exploit the > Pentium it just found out about might SIGILL if it happened to get > dispatched on a lesser processor. Binding is available with processor_bind(). > > I only open this up because I have to make a choice for PowerPC. > > If I follow the existing pattern, is that OK? > > It may be the case that using any value other than the Lowest Common > Denominator ISA unleashes all sorts of terrible problems, and so absent > a specific demand for detailed processor information, your proposal > is exactly the right thing to do. > > I don't have a strong assertion that we must return detailed processor > information, but I think the question should be explored a bit further > before we legislate processor-exploiting apps out of existance. > > > Can we take the idea of expanding the information provided by > > processor_info as a separate (future) RFE, and approve the proposed > > implementation as merely following the existing practice? > > Clearly adopting your convention could not break any existing x86 > applications, since they have all been getting i386 anyway. Could > any SPARC apps be broken by limiting the specificity of ISA values? Nothing I'm proposing changes anything on x86 or SPARC. They continue to get the values they've been getting ('i386' or 'sparc'). Joe From r.@jetsun Wed Mar 29 10:08:34 1995 Date: Wed, 29 Mar 1995 10:07:58 -0800 From: r.@jetsun (David R.) To: psarc@radio, jre@radio Subject: Re: fast-track processor_info(2) for PowerPC PSARC/1995/077 Cc: powerpc@mtns Content-Length: 933 > Discussion: > > Some people have suggested returning more information such as > "PowerPC,604", or (on SPARC), the manufacturer and model of the CPU > chip. We could, but I don't see any good reason to do this. That > information can be obtained (albiet a bit more awkwardly) from the > prtconf command, uname -i, or /dev/openprom driver. It seems better > to keep the information available from processor_info(2) as simple as possible. My opinion is that based on historic use, processor_info should return what can be considered the instruction set architecture. For x86 dispite minor differences 386, 486, and pentium are all part of the i386 architecture, likewise sparc is sparc is sparc. For the Solaris PowerPC it should be "ppc" as proposed. I don't buy the awkward argument, if applications want more detailed descriptions they can use sysinfo(SI_PLATFORM) and take the appropriate optimized procedures. -David From yak@ramses Wed Mar 29 10:22:45 1995 Date: Wed, 29 Mar 1995 10:22:21 -0800 From: yak@ramses (Yousef K.) To: psarc@radio, jre@radio Subject: Re: fast-track processor_info(2) for PowerPC PSARC/1995/077 Cc: powerpc@mtns Content-Length: 849 > From r.@jetsun Wed Mar 29 10:08 PST 1995 > > > > Some people have suggested returning more information such as > > "PowerPC,604", or (on SPARC), the manufacturer and model of the CPU > > chip. We could, but I don't see any good reason to do this. That > > information can be obtained (albiet a bit more awkwardly) from the > > prtconf command, uname -i, or /dev/openprom driver. It seems better > > to keep the information available from processor_info(2) as simple as possible. > > My opinion is that based on historic use, processor_info should return > what can be considered the instruction set architecture. Agreed. If someone really wants to find more information about their CPU (and I am not sure why and even if it is a good idea), they can use one of the other interfaces. Yousef From brianh@swift.West.Sun.COM Wed Mar 29 10:24:22 1995 Date: Wed, 29 Mar 1995 10:21:06 -0800 From: brianh@swift.West.Sun.COM (Brian H.) To: David.R.@Eng, Joe.E.@Eng, psarc@radio.Eng.Sun.COM Subject: Re: fast-track processor_info(2) for PowerPC PSARC/1995/077 Cc: powerpc@mtns.Eng.Sun.COM Content-Length: 510 > I don't buy the awkward argument, if applications want more detailed > descriptions they can use sysinfo(SI_PLATFORM) and take the appropriate > optimized procedures. This doesn't work. sysinfo(SI_PLATFORM) reports the platform information, not anything about the processor within the platform. While it *may* be that one can be inferred from the other, it is not necessarily true. For instance we currently have IBM Power Personal System Model 6015 machines with both 601 processors and 604 processors. From c.@political Wed Mar 29 11:34:57 1995 Date: Wed, 29 Mar 1995 11:35:55 +0800 From: c.@political (Steve C.) To: psarc@radio, jre@radio Subject: Re: fast-track processor_info(2) for PowerPC PSARC/1995/077 Cc: powerpc@mtns Content-Length: 644 For what it's worth, SMCC is going to request that Solaris 2.6 include a "canirun" command and library call (draft specification semi-completed) that will provide a nice clean interface for answering the question "does this machine have this instruction set in the hardware?". Clearly, uname -p and processor_info, as designed, do not let folks get the extra info they want. But changing them breaks existing applications. This fast-track just adds the PPC names to the existing interfaces. We need a different interface (canirun, which will be a different case once it gets submitted) to handle all the issues people are raising. --Steve From brianh@swift.West.Sun.COM Wed Mar 29 11:45:29 1995 Date: Wed, 29 Mar 1995 11:42:20 -0800 From: brianh@swift.West.Sun.COM (Brian H.) To: Joe.E.@Eng, Steve.C.@Eng, psarc@radio.Eng.Sun.COM Subject: Re: fast-track processor_info(2) for PowerPC PSARC/1995/077 Cc: powerpc@mtns.Eng.Sun.COM Content-Length: 687 > For what it's worth, SMCC is going to request that Solaris 2.6 include > a "canirun" command and library call (draft specification > semi-completed) that will provide a nice clean interface for answering > the question "does this machine have this instruction set in the > hardware?". Hmmm... "canirun" and "does this machine have this instruction set in the hardware" are not the same question. What about when particular hardware features are emulated in software (e.g. floating point emulation). Does "canirun" answer "true" or "false". With emulation the answer is clearly "true", but "does this macine have this instruction set in the hardware" the answer is clearly "false". From c.@political Wed Mar 29 11:50:37 1995 Date: Wed, 29 Mar 1995 11:51:35 +0800 From: c.@political (Steve C.) To: Joe.E.@Eng, psarc@radio.Eng.Sun.COM, brianh@swift.West.Sun.COM Subject: Re: fast-track processor_info(2) for PowerPC PSARC/1995/077 Cc: powerpc@mtns.Eng.Sun.COM Content-Length: 718 >Hmmm... "canirun" and "does this machine have this instruction set in >the hardware" are not the same question. What about when particular >hardware features are emulated in software (e.g. floating point >emulation). Does "canirun" answer "true" or "false". With emulation >the answer is clearly "true", but "does this macine have this >instruction set in the hardware" the answer is clearly "false". Heisenberg Uncertainty Principle: The answer you get depends on the question you ask. The proposed spec for canirun allows you to ask many different questions, including the (at least) two implied above. I'm not going to go into detail now; that can be done when the canirun case comes before PSARC. --Steve From jre@radio Wed Mar 29 14:43:07 1995 Date: Wed, 29 Mar 1995 14:45:11 -0800 From: jre@radio (Joe E.) To: psarc@radio.Eng.Sun.COM, brianh@swift.West.Sun.COM, c.@political Subject: Re: fast-track processor_info(2) for PowerPC PSARC/1995/077 Cc: powerpc@mtns.Eng.Sun.COM Content-Length: 264 This proposal was approved at today's PSARC meeting. We'll just say 'ppc'. I understand the desire to get more info on the exact processor type, and if there's enough need for that someday, we can design and implement that as a separate project. Thanks, Joe From roland.mainz@nrubsig.org Wed May 6 19:54:41 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n472sd2C008114 for ; Wed, 6 May 2009 19:54:40 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n472sXGC029298; Thu, 7 May 2009 03:54:38 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJ900E0J6QXUH00@nwk-avmta-2.sfbay.sun.com>; Wed, 06 May 2009 19:54:33 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ900BSP6QX2670@nwk-avmta-2.sfbay.sun.com>; Wed, 06 May 2009 19:54:33 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n472lgI1023995; Thu, 07 May 2009 02:54:32 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-1721496; Thu, 07 May 2009 02:54:32 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-524814; Thu, 07 May 2009 02:54:32 +0000 (Z) Received: from mail-in-09.arcor-online.net ([151.189.21.49] [151.189.21.49]) by relay1i.sun.com with ESMTP id BT-MMP-5769081; Thu, 07 May 2009 02:54:32 +0000 (Z) Received: from mail-in-10-z2.arcor-online.net (mail-in-10-z2.arcor-online.net [151.189.8.27]) by mx.arcor.de (Postfix) with ESMTP id E20561AF2FA; Thu, 07 May 2009 04:16:49 +0200 (CEST) Received: from mail-in-11.arcor-online.net (mail-in-11.arcor-online.net [151.189.21.51]) by mail-in-10-z2.arcor-online.net (Postfix) with ESMTP id CA18723D2B5; Thu, 07 May 2009 04:16:49 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-094-219-212-156.pools.arcor-ip.net [94.219.212.156]) by mail-in-11.arcor-online.net (Postfix) with ESMTPS id 27B9EE38FE; Thu, 07 May 2009 04:16:48 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n472GkrR002190; Thu, 07 May 2009 04:16:47 +0200 (CEST) Date: Thu, 07 May 2009 04:16:46 +0200 From: Roland Mainz Subject: Requesting ARC cases 1993/685, 1994/188, 1994/196, 1994/197, 1994/302, 1995/077, 1995/082, 1995/153 Sender: gisburn@jupiterb48.nrubsig.org To: opensolaris-arc@opensolaris.org Cc: Bonnie Corwin , "PSARC-EXT@sun.com" , emerging-platforms-discuss@opensolaris.org Message-id: <4A02448E.1AC9B6BA@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-11.arcor-online.net 27B9EE38FE X-Antispam: No, score=0.0/5.0, scanned in 0.057sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ x_sac_archived: PSARC/1993/685 x_sac_archived: PSARC/1994/188 x_sac_archived: PSARC/1994/196 Status: RO Content-Length: 704 hi! ---- I'd like to request to open the following ARC cases for publish access: PSARC 1993/685 PowerPC_ABI PSARC 1994/188 Solaris Kernel for PowerPC PSARC 1994/196 PowerPC Header Files PSARC 1994/197 PowerPC Commands PSARC 1994/302 PowerPC_Booting PSARC 1995/077 processor_info(2) binding for PowerPC and future ISAs PSARC 1995/082 PowerPC sysconfig parameters PSARC 1995/153 PPC installboot We need this materials as template for a set of ARC casess to specify support for a new architecture/hardware platform... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)