HDTenEightyP/NetNews huggingface dataset:
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: No Last Call Optimization on Sparc and DECstation
Date: 2 Jan 93 03:16:53 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

bmtong@cs.cuhk.hk (Tong Bo-Ming) writes:
>In the field of Logic Programming, we have a kind of optimization
>technique called the Last Call Optimization.  The idea is simple.
...
>In the above procedure, we may discard the current stack frame (or reg
>window in Sparc) before calling z.  We then replace the call z
>instruction by a jump instruction.
...
>In the above kind of procedure where there is only one call, no stack
>frame is necessary.  It can be optimized as if it were a leaf procedure.
>
>It is a sad thing to notice that such a nice optimization is not
>implemented in languages other than Prolog and on RISC architectures.

	I think you need to look at more compilers.  The SAS/C 680x0
compiler for the Amiga does both of these.

-- 
GNU Emacs is a LISP operating system disguised as a word processor.
 - Doug Mohney, in comp.arch

Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
jesup@cbmvax.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
Newsgroups: comp.arch
From: zrepachol@cc.curtin.edu.au
Subject: Re: Any use for Branch if Even/Odd ?
Organization: Curtin University of Technology
Date: Mon, 28 Dec 1992 12:32:31 GMT

In article <JAN.92Dec15131734@pallas.neuroinformatik.ruhr-uni-bochum.de>, jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) writes:
> In article <1992Dec14.203631.16388@CSDNewsHost.Stanford.EDU> 
> andy@SAIL.Stanford.EDU (Andy Freeman) writes:
> 
>    Does anyone know why they preferred even/odd to >=0/<0?  Sometimes one
>    has to test the sign bit, so why not use it whenever one can use any
>    bit to split things into two classes?
> 
> Part of the reason might be that this distinction (>=0/<0) is used
> in a number of places to distinguish a system address, which has the
> MSB set, from other data, eg. a PID; this is used in I/O completion:
> if <0, the PID cell is reinterpreted as a routine in system space
> to call, as this I/O has been started by some system component and 
> not a user process.)
> 

No, No, No... It was in BLISS before the vax was speced, let allone VMS written.

The pain of 0/~=0 is that you have a horror session in getting ~true to always
be false and visa versa. To parody some user code from a vax system...

TRUE  = byte 1
False = byte 0   IBMs don't have bits, and we must be 'standard'
...
foo = ~TRUE      foo now contains 376 oct, not 0
...
if FALSE(foo)    ah hum,... oh shit...
...

Add in programers who inc/dec logicals and life can soon become a nightmare

~Paul

PS The above example is lifted from a real life PL/I system that could make
news headlines if it failed...


Newsgroups: comp.arch
Subject: Re: Any new instructions in a i486?
From: rmk@rmkhome.UUCP (Rick Kelly)
Organization: The Man With Ten Cats
Date: Mon, 21 Dec 1992 05:32:09 GMT
Reply-To: rmk@rmkhome.UUCP (Rick Kelly)

In article <WAYNE.92Dec20171036@backbone.uucp> wayne@backbone.uucp (Wayne Schlitt) writes:
>In article <9212200017.12@rmkhome.UUCP> rmk@rmkhome.UUCP (Rick Kelly) writes:
>
>< >(somebody)> NeXTStep is said to not run on the Cyrix 486 chips because
>< >(somebody)> "they are not real 486's".  No one has come up with a
>< >(somebody)> reliable reason _why_ NeXT doesn't think they are "real
>< >(somebody)> 486's" or why NeXTStep won't run on them.
>< >
>< >FUD, FUD. Ah Intel, Intel. :-)
>< 
>< 
>< I don't see where this has anything to do with Intel.  Cyrix decided that
>< they could make some money by cloning a best selling CPU chip.  Obviously,
>< they have missed something.  
>
>
>Well, from the info that has been posted so far, it looks more and
>more like it is NeXT that screwed something up and doesn't care about
>fixing it.  Chances are NeXTStep won't run on the Pentium either if it
>is that fragile.


Except they will fix any Pentium problems quickly.

Someone needs to drag out the logic analyzers.

Does GCC, which NeXT uses, have a "-i486" flag that causes some wierd
code optimization, or is this just my imagination?

NeXTStep for Intel seems to be the only dedicated 486 package around.

-- 

Rick Kelly	rmk@rmkhome.UUCP	unixland!rmkhome!rmk	rmk@frog.UUCP
Xref: sparky comp.arch:11865 comp.sys.intel:2812
From: shoens@rufus.almaden.ibm.com
Newsgroups: comp.arch,comp.sys.intel
Subject: Re: Superscalar vs. multiple CPUs ?
Date: 22 Dec 92 17:41:13 GMT
Reply-To: shoens@almaden.ibm.com
Organization: IBM Almaden Research Center

Jason Solinsky  ...

> In how many of these examples are we actually concerned with processor
> performance?  In editors and word processors we certainly aren't ...
> In the case of a database, I would not expect it to be processor limited.

As you have more cycles to fool with you get to put more function in,
of course.  So where I previously edited nroff source with ed, I now
use a system like Framemaker with X-windows.  Database systems are
typically CPU bound because disks have been slow forever, so the problem
of disk parallelism has already been tackled.  Besides, if you analyze
the popular transaction benchmarks you can see that the disk bandwidth
required is relatively small, assuming reasonably-sized buffer pools.
For complex queries, there's even more processing to do and more opportunity
for smart data placement on disk and sequential prefetch.
--
Kurt Shoens
Xref: sparky comp.arch:11909 comp.sys.intel:2828
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch,comp.sys.intel
Subject: Re: Superscalar vs. multiple CPUs ?
Date: 23 Dec 92 19:49:41 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <Bzpzwq.18q@news.udel.edu>, mccalpin@perelandra.cms.udel.edu (John D. McCalpin) writes:

| Although I don't think it was ever done, the world's fastest text
| editor could probably have been written for the ETA-10, which had a
| bewildering variety of instructions for copying and searching chunks of
| its bit-addressable memory at vector speeds.   The Cray machines could
| be competitive, but the lack of byte addressability makes working with
| text awkward and relatively slow.

  Would you believe a Cray2 runs troff slower than a Sun? I have some
old results which certainly seem to show this, and having used text
editors on the Cray I'm willing to believe it.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.
From: cecchi@rchland.vnet.ibm.com (Del Cecchi)
Subject: Re: IBM AS/400 is the world's slowest computer
Date: Mon, 21 Dec 1992 14:15:58 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester

In article <1992Dec20.221103.13995@ksmith.uucp>, keith@ksmith.uucp (Keith Smith) writes:
|> In article <1992Dec18.165950.15013@webo.dg.com> lewine@cheshirecat.webo.dg.com writes:
|> >IBM is currently running full-page Ads that claim "The AS/400
|> >is the world's most powerfull computer with the industry's best
|> >price/performance(*)"
|> >
|> >"(*) According to the TPC-C benchmark results published through
|> >     12/3/92"
|> >
|> 
|> Yea, I laughed so hard my sides ached!
|> 
|> >IBM does not point out the the AS/400 is the only computer with
|> >TPC-C results published as of 12/3/93.  The AS/400 is also the
|> >world's slowest and most expensive computer by the same benchmark.
|> 
|> Dog slow.  But to the people who buy them they don't care.  The fact is
|> the AS/400 runs their apps that they have ported up from S/3 cards for
|> the last 20 years, and they are too lazy to try something different, so
|> they pay, and pay, and pay....
|> 
|> >
|> >Do people fall for this stuff?  IBM claims that the AS/400 is the
|> >best selling mid-range system in the world, so someone must fall
|> >for it.
|> 
|> Compile time for a 1000+ line program on a 486/33 w/8MB RAM using UNIBOL
|> RPG was about 8 times faster than an AS/400 B20 with 8MB RAM.  Seconds
|> as opposed to minutes.  Again, IBM will hold your ignorant MIS
|> departments hands from purchase, to setup to delivery.  All they'll have
|> to is write even more indicator mad code that takes forever to run, that
|> will of course require an even bigger AS/400 (or perhaps a 486/33 with a
|> better compiler ...)
|> 
|> If you own one, pray no one nukes the New England plant where all 100 or
|> so people that know AS/400 internals work.

New England?.  Gee I always thought Minnesota was considered part of the Midwest.
 The AS/400 is developed in Rochester MINNESOTA.  And we have a few more than 100
people out here on the tundra doing development.  

I take it you don't like RPG? :-).   Talking about B series models when the
current machines are E  or something like that is also sort of a cheap shot also.
 So How does that 486 run when you put 10 or 20 users on it doing order entry?.  

|> 
|> >--------------------------------------------------------------------
|> >Donald A. Lewine                (508) 870-9008 Voice
|> >Data General Corporation        (508) 366-0750 FAX
|> >4400 Computer Drive. MS D112A
|> >Westboro, MA 01580  U.S.A.
|> >
|> >uucp: uunet!dg!lewine   Internet: lewine@cheshirecat.webo.dg.com
|> 
|> 
|> -- 
|> Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
|> Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
|> Somewhere in the Styx of North Carolina ...

-- 

Del Cecchi  
cecchi@rchland
Xref: sparky comp.arch:11884 comp.sys.dec:6607 comp.sys.sgi:18292 comp.sys.hp:14326
From: mjr@TIS.COM (Marcus J. Ranum)
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Date: 23 Dec 92 03:50:00 GMT
Reply-To: mjr@TIS.COM
Followup-To: comp.arch
Organization: Trusted Informations Systems, Inc.

bruce@ais.com (Bruce C. Wright) writes:

>I find `stock'
>Unix much worse than VMS in terms of productivity mostly because
>of that horrible `vi' editor that comes with it :-).

	In fact, most "operating systems wars" boil down to preferences
as simple as these. I realize that Bruce had a 'smiley' to indicate that
he was joking, but it seems that whenever the VMS-versus-UNIX or
UNIX-versus-DOS or whatever war starts up, sooner or later it winds
up boiling down to text editors and window systems and help systems
and the really piddly triviata that have *NOTHING* to do with the
operating system and everything to do with the operating environment.

	Usually, once the "discussion" has boiled down to this final
remnant of sticky pure opinion goo at the bottom of the crucible, most
sensible people realize it's time to find something worthwhile to
talk about. Arguing about environments is stupid. Especially when
it comes to editors and you can buy TPU for UNIX and get vi clones
for VMS.

	Here's an interesting postulate to argue about: operating
system kernel technologies aren't interesting anymore. Whether it
is VMS or UNIX or NT or FooFrATz is meaningless if the system
*environment* ("environment" == utilities, user interface, system
libraries, network interface, etc) does what you need it to do.
The question, I submit, is not "UNIX or VMS?" it is "what do I
need for this *particular* project?" - and that depends on the
project, programmer skills, requirements, etc - and is not worth
arguing about on USENET.

mjr.
From: dswartz@sw.stratus.com (Dan Swartzendruber)
Newsgroups: comp.arch
Subject: branch-and-link
Date: 27 Dec 92 17:54:11 GMT
Organization: Stratus Computer, Inc.
NNTP-Posting-Host: redondo.sw.stratus.com

Here's a question for the hardware types: is there any reason either of
design complexity or performance to not have *all* branches (conditional
and unconditional) save their origin somewhere (probably in a fast
dedicated register)?  I know various cpu's (the rs6000?) have done this
in the past, but only as an option.  If there is no negative impact to
doing this, it would be a real win for debugging crashes where a program
(application or kernel) branch off to nowhere and die - and the poor S/W
type is left guessing...

-- 

#include <std_disclaimer.h>

Dan S.
Newsgroups: comp.arch
From: peter@ferranti.com (Peter da Silva)
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Organization: Xenix Support, FICC
Date: Wed, 30 Dec 1992 19:13:37 GMT

In article <1992Dec29.003728.9977@ryn.mro4.dec.com> Peter.Mayne@cao.mts.dec.com writes:
> NT (for example) supports at least two file systems, DOS and NTFS. NTFS has
> ACLs, DOS doesn't. If an operating system object is a file,

In UNIX it is. Apparently in NT a file is a special case of an object.

> which filing
> system does it use?  If I only use DOS, does that mean that NT suddenly loses
> the ability to use ACLs?

At least on those objects, yes.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
Newsgroups: comp.arch
From: dhd@exnet.co.uk (Damon)
Subject: Re: Def of a workstation (a lark)
Organization: ExNet Systems Ltd Public Access News, London, UK
Date: Sun, 3 Jan 1993 20:53:52 GMT

In article <1993Jan3.052930.27869@wam.umd.edu> rsrodger@wam.umd.edu (Yamanari) writes:
>	Can anyone give me a definition of workstation, other than 
>	cost, that seperates it from modern high-end PC systems (in his
>	case, one that cost no more than $3500).  
>
>	At first I was tempted to talk about UNIX or RISC, but these
>	were less than satisfactory (UNIX because he could be running
>	UNIX, and RISC sounds deficient--those old M68k based Suns are
>	still workstations...and then there's the 386i...)..

[M68k Suns---sure, my office is stuffed with them and this is written
 on one right now!]

A workstation is probably best characterised as an `integrated' system,
generally running UNIX, built for performance more than cost (though
Sun is doing its best to muddle the picture), and with a decent
graphics screen and GUI bundled.  Ie a minimum of DIY and a maximum of
performance and a UNIX box.

Now, if when you bought your PC it came with UNIX and a GUI all from
the same source, it would be a workstation, methinks.

Only my UK#0.017...  (exchange rates may vary B^>)

Damon
-- 
Damon Hart-Davis                          Internet: dhd@exnet.co.uk, d@hd.org

Public-access UNIX (Suns), news and mail for UK#5 per month.  FIRST MONTH FREE.
[1.35] Cheap Sun eqpt.  UUCP news/mail feeds.  Tel/Fax: +44 81 755 0077.
Xref: sparky comp.arch:11897 comp.sys.intel:2822
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: reentrant
Date: 3 Jan 93 01:31:18 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

john@iastate.edu (John Hascall) writes:
>firth@sei.cmu.edu (Robert Firth) writes:
>}>The OS world is moving towards multithreading...
>
>}It is with some trepidation that I amend one of Don Lindsay's comments,
>}but in my experience it is only the C/Unix world that is moving towards
>}multithreading.  The rest of the world has been there for a very long time.
>
>Perhaps the research world has been...
>But as far as (popular) commercially available OSes, it would seem not:
>
>  MS-DOS:  not a chance
>     VMS:  nope
>     MVS:  sort of, but horrid
>      VM:  I dunno, and I hope never to find out ;-)
>    OS/2:  ditto
	    Yes, as I understand it.
>    UNIX:  not yet
>   OSF/1:  yes, but not much of a commercial success at this point

  AmigaOS:  Yes (actually it's kind of your only choice)
    MacOS:  No
TOS (yech): No, maybe with the vapor-ish "Falcon"
       NT:  Yes, I think (not sure).

Note that most/all of the OS's _designed_ after about '85 or so have some level
of preemptive thread support (AmigaOS, OS/2, NT, sort-of-new OSF/1).  TOS is
running a modified CPM/68K (aka pre-85), so I don't count it.  The MacOS might
have had it (Lisa was multitasking), but tasking got dropped.  The MacOS will
probably have it sometime in the future.

Of course, the definition of "thread" may vary...

-- 
GNU Emacs is a LISP operating system disguised as a word processor.
 - Doug Mohney, in comp.arch

Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
jesup@cbmvax.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
From: pmorris@chessie.East.Sun.COM (Phillip Morris - SE Vienna Va.)
Newsgroups: comp.arch
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-
Date: 21 Dec 1992 20:24:53 GMT
Organization: Sun Microsystems, Inc.
Distribution: world
Reply-To: pmorris@chessie.East.Sun.COM
NNTP-Posting-Host: chessie.east.sun.com

In article 37C@dscomsa.desy.de, hallam@zeus02.desy.de (Phill Hallam-Baker) writes:
>
>Bugs they still need to fix:-
>
>	1) Online manual still designed with aim of minimizing disk space rather than
>providing information.

Try out Sun's Answerbook technology (will take up over 200MB of disk if you install
the whole thing), with hyper-text links throughout, a great search facility, etc.

>	2) No help facility.

Almost every vendor now has a help viewer pop-up in their windows environment. For
Suns, just hit the Help key (if you haven't disable it) while in Openwindows.

>	3) No standardized user firendly shell.

What's a user-friendly shell? There sure are plenty to choose from, take your pick from
sh, csh, ksh, tcsh, bash, etc.

>	4) Command qualifiers hard coded into applications making multilanguage
>customization impossible.

Take a look at Solaris 2.1 -- it has extensive I18N (internationalization) support
at both the O/S and the programmer's levels.

>	5) Requires expensive expert to have a chance of any security.

Sun's CMW (shipping in volume as of 12/17/92) only needs a regular admin and a
security officer (who is required for any secure facility anyhow), and is being
evaluated for the DISA CMW (B2+ security).

>	6) File system limited to sequential file, forcing applications to create their
>own file system on top of the UNIX one, thus preventing any standardization or
>application independent optimization.

Almost every Unix implementation now has many optimizations built-in, such as write
clustering, SCSI tag-queuing, etc.  You can also create holey files.  Striping (both
via h/w and s/w) is abundantly available.  What type of file I/O are you complaining
about the lack of?

>Phill Hallam-Baker

-Phil Morris



Newsgroups: comp.arch
From: meissner@osf.org (Michael Meissner)
Subject: Re: reentrant
Organization: Open Software Foundation
	<1993Jan2.122544.26198@sei.cmu.edu> <C08qF4.Knz@news.iastate.edu>
Date: Sun, 3 Jan 1993 23:50:14 GMT

In article <C08qF4.Knz@news.iastate.edu> john@iastate.edu (John Hascall) writes:

| Perhaps the research world has been...
| But as far as (popular) commercially available OSes, it would seem not:
| 
|   MS-DOS:  not a chance
|      VMS:  nope
|      MVS:  sort of, but horrid
|       VM:  I dunno, and I hope never to find out ;-)
|     OS/2:  ditto
|     UNIX:  not yet
|    OSF/1:  yes, but not much of a commercial success at this point

Data General's propitary operating systems (R[TD]OS, AOS{,/VS,/VS-II}
have had threads (called tasks) since the 70's (early 70's I think).

Many of the multiprocessor UNIX versions have had threads in one form
or another, and certainly the MPP systems.
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

You are in a twisty little passage of standards, all conflicting.
From: gjr@zurich.ai.mit.edu (Guillermo J. Rozas)
Newsgroups: comp.arch
Subject: Re: No Last Call Optimization on Sparc and DECstation
Date: 2 Jan 93 08:01:44
Organization: M.I.T. Artificial Intelligence Lab.
Reply-To: gjr@zurich.ai.mit.edu
NNTP-Posting-Host: chamartin.ai.mit.edu
In-reply-to: bmtong@cs.cuhk.hk's message of Wed, 30 Dec 1992 09:43:52 GMT

In article <1992Dec30.094352.4243@cucs5.cs.cuhk.hk> bmtong@cs.cuhk.hk (Tong Bo-Ming) writes:

   It is a sad thing to notice that such a nice optimization is not
   implemented in languages other than Prolog and on RISC architectures.

Proper tail recursion is a semantic requirement of Scheme (and I think
ML), thus compilers for these languages have to implement this
"optimization".
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: IBM AS/400
Date: 25 Dec 92 05:04:54 GMT
Article-I.D.: cs.Bzsu47.Lxv.2
Organization: School of Computer Science, Carnegie Mellon

In article <1992Dec25.033918.3246@beaver.cs.washington.edu> kolding@cs.washington.edu (Eric Koldinger) writes:
>There's a fundamental difference between hardware and software capabilities.
>Software capabilities can be forged, however improbable.

You may have seen such a system, but some software-based systems
really are fully secure. The OS keeps all of the unforgable bit
patterns in some system space. The user processes manipulate values
which the OS effectively treats as indexes. Forging an index gains a
process no abilities that it didn't have already.

>On an architecture like the AS/400, EVERY memory reference is
>checked against a capability, and individual bytes can be protected.
>Software capabilities are typically used to protect larger grained
>objects, and are only checked when that object is "bound" to your
>protection domain.

Agreed. However, conventional machines check every memory reference
with an MMU. On these, binding an object in === teaching the MMU
about the object. So, the real difference is that conventional MMUs
are page-oriented rather than byte-span oriented. [Well, the time
cost of a binding probably differs.]

There have been MMUs that allowed fractional pages - for example,
the front part, or the rear part, of a page could be missing.
The PDP11/45 supported this with a 64-byte granularity.

The AS/400 may support tiny objects, but does it gain much from doing
so?
-- 
Don		D.C.Lindsay	Carnegie Mellon Computer Science
Newsgroups: comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: IBM AS/400 is the world's slowest computer
Organization: Xenix Support, FICC
Date: Tue, 22 Dec 1992 15:36:33 GMT

In article <1992Dec21.141558.18626@rchland.ibm.com> cecchi@rchland.vnet.ibm.com (Del Cecchi) writes:
>  So How does that 486 run when you put 10 or 20 users on it doing order
> entry?.  

I'd hope it'd run pretty damn well, since we've had up to 10 users on a 286
doing software development... which is about 30 times slower than the 486,
with more demanding users.

Now I won't say I was happy with the performance on the 286, but the current
systems with moderately old 386es are adequate, and our 486 box screams.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
Newsgroups: comp.arch
From: goyal@utdallas.edu (MOHIT K GOYAL)
Subject: Novice ? about Intel-based PC architectures...
Organization: Univ. of Texas at Dallas
Date: Sun, 3 Jan 1993 07:10:21 GMT

Hello.

I am wondering if anyone can tell me what would be the best arch. for a
486 system running a multitasking OS. (OS/2)

I don't know if VL-Bus, EISA, the upcoming PCI, or any combination of the
3 is best.

What would perform the best on a 486(or 586) class machine, or rather, what
would give the best performance?

Finally, say EISA is the best of all, is the performance difference 
noticable in the "real world"? or would it be like saying a 486SX-25
is "better" than a 386DX-40? (10% actual difference, no "real world"
difference).

I will be purchasing a system in a couple of months and would just like
to get the best performance.  Price is not a factor, but I don't want
to spend a billion more for type A, if type B is only 5% worse, if you
know what I mean.

If it matters, I will be writing C & C++ programs, using AutoCAD, playing
games, writing, and using my v32bis modem on the system.

Thanks.