HDTenEightyP/NetNews huggingface dataset:
From: greg@gmp.lonestar.org (G.R. Basile)
Newsgroups: comp.dsp
Subject: Re: compilers for DSP processors
Keywords: compilers, dsp, assembly language, vliw, c
Date: 22 Dec 92 14:58:02 GMT
Organization: GMP Research Co., Dallas TX

malcolm@Apple.COM (Malcolm Slaney) writes:

> cmh@eng.cam.ac.uk (C.M. Hicks) writes:
> >DSP chips are designed to be fast, and to slow them down with compiled code
> >seems daft, particularly in real-time applications. 
> 
> On most reasonable processors, people have found that the compilers write
> better code than humans do.  Compilers can do a much better job of global
> register allocation, scheduling, and all the other things that make for
> good translations.  This is especially true of today's RISC machines (DEC,
> IBM, HP, Sun, Cray, MIPS). For a good exposition of the power of a compiler, 
> read John Ellis' book on the Bulldog compiler for VLIW machines.
> 
well, since you drag in RISC chips,

I did an application that decompressed G4 images and then scaled the images for
a for a 300 page per minute printer . The C compiler was GNU and the risc was the 
Intel 80960CA. The code had beed optimized a lot in C and was still not fast
enough.


My usual experience with C compilers on DSP's  that a 8 to 10 x increase 
in speed is possible in the c to asm port. After looking at the output 
of the GNU 80960 C compiler, I was impressed with the efficiency of the 
assembler output. I estimated that the increase in speed in the c to asm 
port would be a factor of 2 at best. I was able to attain a 3x speed increase
on the G4 decompression code and A 8X IMPROVEMENT on the scaling code.

This speed increase was due to 1) using a machine instruction the 
complier was clueless about, and 2) an optimization of the scaling algorithmn
that would have been not obvious at the compiler level.
> 
> Listen up DSP makers....compilers can write better assembly code than us
> mere humans.....especially if you give the compiler a chance.  Pay attention
> to the lessons that the RISC people taught the CISC dinasours.
> 
DSP makers... I would rather you use the extra microcode on the processors to
give a fast, application specific instructions than to create instructions 
that would make a C compiler more efficient.

Greg Basile
Newsgroups: comp.dsp
From: brucet@extro.ucc.su.OZ.AU (Bruce Tulloch)
Subject: Is the 96K an orphan chip ?
Keywords: dsp 96002
Organization: Sydney University Computing Service, Sydney, NSW, Australia
Date: Mon, 4 Jan 1993 02:13:49 GMT

My question for the DSP community is,

	Is the DSP96002 an orphan chip ?

Motorola have produced some very good DSP chips over the last 5 or so
years and I have used both the 56K and 96K effectively in a variety of
projects. However, these days the competition is getting fierce. With
the C30/C40, 21020, the DSP32C and it's decendants and even the dreaded
i860, the 96K has a lot of company.

Once upon a time (circa '88) Motorola announced the DSP96001 which was
to be "the first member of Motorola's Family of single chip HCMOS,
low-power, general purpose, IEEE floating point DSPs." Whatever
happened to it ? Does anyone know whether Motorola intend to develop
the 96K family further, particularly in the *down market* direction ?

I am aware of the DSP296002 and the functional modifications to the
basic DSP96002 such as the program cache and simultaneous 32 bit
integer and 64 bit floating point register usage - all very nice but
still rather expensive. What I'd really like to see is Motorola do with
the 96K what they are doing with the 56K - lower prices and on-chip
perhiperals. High speed serial ports, communications links, more DMA
etc, maybe at the expense of one of the external memory interfaces,
would be great, just like TI only with the far superior (IMHO) 96K
core. Is this just wishful thinking ? Will it ever happen ? Should I
forget the 96K altogether and use the TI chips for these facilities ?

Maybe the term "digital signal processor" for this chip a misnomer ?
Perhaps "high performance IEEE floating point coprocessor for really
high end applications" is a better name :-)

Any opinions on this subject are welcome :-)

brucet

-- 
          bruce tulloch sydney australia - brucet@extro.ucc.su.oz.au
***complex problems have straight forward, easy to understand wrong answers***
Newsgroups: comp.dsp
From: moshier@world.std.com (Stephen L Moshier)
Subject: Re: Motorola's gcc diffs?
Organization: The World Public Access UNIX, Brookline, MA
Date: Wed, 23 Dec 1992 23:02:38 GMT

  >you will find the complete...
This version seems to work all right, but it generates illegal instruction
sequences.  I was informed by Motorola that there is a post-optimizer
that is required, and that this code was not made freely available.
Although I was able to hack up a simple peephole optimizer to get rid
of the illegal instructions, the gcc code is very inefficient.
I threw the whole thing away.  Perhaps Motorola worked very hard
on their optimizer and it does miraculous things.  Perhaps not.

Newsgroups: comp.dsp
From: moshier@world.std.com (Stephen L Moshier)
Subject: Re: Motorola's gcc diffs?
Organization: The World Public Access UNIX, Brookline, MA
Date: Sat, 26 Dec 1992 16:03:58 GMT

The one I tried is called Version 1.03.  When you try to compile
something with it, it bombs when it gets to the point of looking
for the non-existent optimizer.  The illegal instruction sequences
include using an address register on the instruction after loading it,
and doing a subroutine return on the instruction after modifying
the system stack (i.e. popping the status).

Newsgroups: comp.dsp
From: ja51359@uxa.cso.uiuc.edu (axelrod)
Subject: Re: Wanted: ANSI C/F77 FFT library w/source
Organization: University of Illinois at Urbana
Date: Tue, 22 Dec 1992 16:59:26 GMT

hjermann@cmr.no (Sigmund Hjermann) writes:

>I need a ANSI C or FORTRAN 77 advanced math and/or signal processing software 
>library with source code. I specifically need the real Fast Fourier Transform analysis, 
>statistical analysis, and complex math (C) part of the library(ies). The purpose is to use 
>it in Intel's RMX part of the DOS/RMX API with Intel's compilers.

Try archie fft
From: antsu@polaris.utu.fi (Antti-Pekka Virtanen)
Newsgroups: comp.dsp
Subject: Re: Motorola's gcc diffs?
Date: 26 Dec 92 18:18:19 GMT
Organization: University of Turku, Computing Centre


The following is the gcc/version.c of the gcc source in nic.funet.fi:

/* $Id: version.c,v 1.47 92/05/26 11:01:27 pete Exp $ */
char *version_string = "1.37.1";
/* for motorola DSP: CVS will automatically insert the latest tag, x in between
 * the two @s when cvs tag x gcc is run
 */
char *motorola_version_string = "Motorola 1.03";

It seems pretty much like the original thing to me.

Regds, Antti-Pekka

--
 **************************************************************
 * Mail: Antti-Pekka Virtanen  E-Mail:   antsu@utu.fi         *
 *       Arholankuja 3 as 21             antsu@mea.utu.fi     *
 *       SF-21100 Naantali               antsu@nic.funet.fi   *
 *       Finland                         antsu@sandra.pp.fi   *
 **************************************************************
Newsgroups: comp.dsp
From: "Nathan Gregory" <p00211@psilink.com>
Subject: Re: WANTED: Startrek Sound
Organization: Performance Systems Int'l
Date: Tue, 29 Dec 1992 19:46:20 GMT
X-Mailer: PSILink-DOS (3.3)

There is a commercial PC package called Whoop_It_Up which has
three disks chock full of ST:TNG sounds including all of the
described ones.  Santa brought mine so I don't know where to
buy it or what it costs, but I would expect Fry's, Egghead or
CompUSA to have it.

NTG
From: rsl11@kuhub.cc.ukans.edu
Newsgroups: comp.dsp
Subject: SOUND FILE FORMATS..NEED SOME HELP..
Date: 29 Dec 92 03:59:01 CST
Organization: University of Kansas Academic Computing Services

Hello there,

	I am looking for some good documentation or explanation on how to use the
program "sox" that is used to convert from one sound file format to another. I am 
using the program x_soundtool and I am recording speech and it stores it in an
audio file that is ulaw encoded 8-bits. What I would like to do is to convert it
back to linear encoding and get the actual numerical values for futher processing.
I have used the program "ulaw2linear" that converts I believe 8 bits ulaw to 
16 bits linear(according to some documentation I read about file formats) but it 
puts a header which I don't know whether the header is only attached in the beginnig.
I tried different possibilities but I don't seem to get any good results.

	Also, if I could get some information on how to use the program "sox" it
would be great(how to use the different parameters such as -t, -b, -x etc).

	I would appreciate any relevent response. Feel free to send mail to 
the following e-mail address:
Internet:rsl11@kuhub.cc.ukans.edu
Bitnet: rsl11@ukanvm.bitnet

Thanks.....
Newsgroups: comp.dsp
From: moshier@world.std.com (Stephen L Moshier)
Subject: Re: Motorola's gcc diffs?
Organization: The World Public Access UNIX, Brookline, MA
Date: Fri, 1 Jan 1993 23:36:05 GMT

Yes, I told them I was compiling the source code that I got from a
computer in Finland.  They thought it was very funny.  It seems to
be the only way to get the compiler to run on a Motorola Delta box.
The particular Unix on it has trouble compiling gcc, so that
problem still isn't solved.

By the way, I did pay the $120 upgrade fee.  I received an update
of the assembler, which doesn't work on a 286 PC.  I did not
receive the C compiler.  The distributor seems hopelessly
confused about the part numbers, which are apparently the
same whether it's $120 or $709.  Am I supposed to pay
one $120 for the assembler update and another $120 for the
compiler update?
From: reed@rd08.wg2.waii.com (Michael Reed)
Newsgroups: comp.dsp
Subject: Two-dimensional Wiener Filter
Date: 21 Dec 92 23:25:34 GMT
Reply-To: reed@rd08.wg2.waii.com
Organization: Western Geophysical Research & Development

Has anyone had any experience solving for a two-dimensional
AR model?  I am trying to use the routines out of Marple's
book, "Digital Spectral Analysis", but they appear to be
unfinished.  Any comments or suggestions would be appreciated.

Mike
-- 
The above are my own opinions and mine alone.

*****************************************************************************
Dr. Michael Reed,
Western Geophysical, Research and Development Group
reed@rd08.wg2.waii.com
(713) 964-6322                     FAX: (713) 964-6372
*****************************************************************************
From: aok@rice.berkeley.edu (Alan Kamas)
Newsgroups: comp.dsp
Subject: Ptolemy 0.4 Release Now Available
Date: 23 Dec 1992 07:45:47 GMT
Organization: University of California, Berkeley
Distribution: world
NNTP-Posting-Host: rice.berkeley.edu
Keywords: cad, dsp, code generation, software

The 0.4 release of Ptolemy is now available.

Ptolemy provides a highly flexible foundation for the specification,
simulation, and rapid prototyping of systems.  It is an object
oriented framework within which diverse models of computation can
co-exist and interact.  For example, using Ptolemy a data-flow
system can be easily connected to a hardware simulator which in turn
may be connected to a discrete-event system, etc.  Because of this,
Ptolemy can be used to model entire systems.

In addition, Ptolemy now has code generation capabilities.  From a
flow graph description, Ptolemy can generate both C code and DSP
assembly code for rapid prototyping.  Note that code generation is
not yet complete, and is included in the current release for
demonstration purposes only.

Ptolemy has been used for a broad range of applications including
signal processing, telecomunications, parallel processing, wireless
communications, optical phase lock loops, real time systems, and
hardware/software co-design.  Ptolemy has also been used as a lab
for signal processing and communications courses.  Currently Ptolemy
has hundreds of users in over 75 sites, both in industry and academia.

Ptolemy is available for the Sun 4 (sparc) and DecStation (MIPS)
architectures.  A port to the HP workstation is in progress.
Installing the system requires 49 Mbytes for Ptolemy (64 Mbytes
after you optionally rebuild) and 16 Mbytes for the Gnu tools
subset.  At least 8 Mbytes of physical memory are required.

Ptolemy has been developed at UC Berkeley over the past 3 years.
Further information, including papers and the complete release
notes, is available from the FTP site.

A license is no longer required to receive Ptolemy.  The source code,
binaries, and documentation are available by anonymous ftp from
	ptolemy.berkeley.edu
[ftp "ptolemy.bekeley.edu". login as "anonymous". cd "pub". get README]
--
Alan Kamas					aok@eecs.berkeley.edu
558 Cory Hall					phone: (510) 643-7683
University of California at Berkeley		fax:   (510) 642-2739
Berkeley, CA, 94720 USA


Newsgroups: comp.dsp
From: jeff@dsp.sps.mot.com (Jeff Enderwick)
Subject: Re: Motorola's gcc diffs?
Organization: Motorola DSP Compilers
	<BzvJAM.H8C@world.std.com> <JEFF.92Dec31092357@dsp.sps.mot.com>
	<C05AvJ.KKD@world.std.com>
Date: 1 Jan 93 17:26:38


>   I paid $700 cash for the original attempt.  Before deciding whether
>to upgrade, I asked Motorola some questions. No, it does not do pipeline
>optimization.  No, data in x, y, p memory spaces are not supported; you
>have to choose either x or y and not both.  No, it does not have a
>fractional data type (can that really be true?).  Well, I decided to
>hold off and stick with the one I made from Dave Dunfield's 8086 C
>compiler.

Kind of. Actually we do attempt to jam multiple instructions into
single words, and we also try to avoid pipeline hazards. If you're
speaking of "software pipelining", we haven't implemented the aliasing
analysis that is needed to do it right. The X / Y memory issue is a
very tricky one.  Given a pointer as an argument, you need to be able
to figure out which data space it belongs to; this implies modifying C
(the language).  Basically, what you get is GCC with some extra
optimizations thrown in.

>   Perhaps TI is the only DSP company that can *afford* a real compiler
>project.  TI, with its near-monopoly market share, has improved its
>software from awful in 1982 to very good in 1992.  (But I can't use
>their chip any more! It always seems to work out slower than the
>alternatives.) Meanwhile the other companies presumably do what software
>support they can, but they sure leave a lot to wish for.  I say, Never
>mind the windows and COFF and source level debuggers, just give us a
>better compiler.

I used to think like you. Personally, I find implementing compiler
optimizations to be the fun part of my job. I wish everyone had your
perspective. Unfortunately for us, most customers don't. If a compiler
is even 10% slower than hand code for time critical loops, then the
DSP engineer is going to hand code them. Maybe you work on projects
where volume is low, and the cost of parts doesn't matter, yielding a
situation where you'd rather spend a little more on a faster part that
take the time to hand code. Most customers who will do high volume 
production will want to use the slowest (cheapest) part that will get
the job done. On some loops you may hit paydirt with a compiler; on
most you're compiled code will be slower that hand code. 

Overwhelmingly, DSP compiler customers seem to use C to speed the
development of the non-time critical sections of their application.
The sections that are tight for time are hand coded. The goal of
introducing better optimizers is to move the frontier where the
engineer needs to hand code. As for debuggers and windows these are a
really big deal. people want to be able to debug systems as easily and
as quickly as possible. Good debuggers are a high priority for most
customers.

I'd be really interested in finding out which TI compiler you're talking 
about (and which version). I'd like to get a copy and look at what comes
out!

	thanks,

	Jeff Enderwick
	jeff@dsp.sps.mot.com
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.soft-sys.andrew
Subject: Re: Andrew on Solaris 2.1
Date: 23 Dec 92 00:02:11 GMT
Organization: Auspex Systems, Santa Clara

>Has anyone done any work on porting Andrew to Solaris 2.1?

Has anyone done any work on porting ATK to *any* SVR4-derived UNIX?  If
so, and if there's more than one place where it's being done, perhaps
the people doing it should get together on that (I can easily imagine
person A porting it to some PClone running SVR4-for-i386, and person B
porting it to Solaris 2.x, and person A and person B having no idea that
the other's doing it).

Note that the right way to do the dynamic linking stuff for SVR4 is
probably to grab the SunOS 4.1[.x] version of the dynamic linking code
and proceeding from there (the "dlopen()"/"dlsym()"/etc. interface was
actually invented by AT&T, although they never released any
implementation until SVR4; Sun just used AT&T's interface for SunOS
4.1[.x]), rather than trying to teach the "do it yourself" code about
ELF (the main reason I did the version that used "dlopen()" and company
was to *keep* people from trying to teach the do-it-yourself version
about ELF).

You will probably also want to change the pseudo-tty handling code in
"typescript" and "tm" to use SVR4-style pseudo-ttys.
From: klute@tommy.informatik.uni-dortmund.de (Rainer Klute)
Newsgroups: comp.soft-sys.andrew
Subject: National characters in texts
Date: 30 Dec 1992 19:57:25 GMT
Organization: CS Department, Dortmund University, Germany
Distribution: world
NNTP-Posting-Host: tommy.informatik.uni-dortmund.de

I just installed some basic parts of the Andrew system (namely messages) on
a Sun IPC (running SunOS 4.1.1) under X11R5, patchlevel 20. What annoys me
is that typing a national character (i. e. a German umlaut) in, say, ez
crashes the application. Is this regarded as usual behavior, could it be
due to my unusual installation, or did I miss anything in the
documentation? Everything else I tried in ez or messages seems to work.

-- 
  Dipl.-Inform. Rainer Klute      klute@irb.informatik.uni-dortmund.de
  Univ. Dortmund, IRB
  Postfach 500500         |)|/    Tel.: +49 231 755-4663
D-W4600 Dortmund 50       |\|\    Fax : +49 231 755-2386
From: a08l@ALF.ZFN.UNI-BREMEN.DE (Paul Wilfried)
Newsgroups: comp.soft-sys.andrew
Subject: literature question (FAQ)
Date: 22 Dec 92 16:43:12 GMT
Distribution: world
Organization: The Internet


Hello,

I have read the following literature tips in the FAQ from June:

>G4.  What books have been written for Andrew and where can I obtain them?
>
>    Nathaniel S. Borenstein's book: Multimedia Applications
>    Development with the Andrew Toolkit (Prentice-Hall).
>
>    ODA Project Book: Multi-media Document Interchange: ODA and the
>    EXPRES Project (Springer Verlag).

Can anybody provide me with a contents list of these books and some comments
about the intended readership and quality? I don't have the possibility here
in Bremen to have a look on the books with the exception of to buy them 
directly. For the ODA book I found the reference:

Rosenberg, J. , et.al.: Multi-media Document Translation. ODA and the 
                                             ^^^^^^^^^^^ !?
Express Project, 1991, ISBN 3-540-97397-4 

Is that the above mentioned book or exists another one ?

Thanks for help in advance and best Xmas and New Year wishes.

Ciao Wilfried

-------------------------------------------------------------------------------
Dipl.-Inform. Wilfried Paul		Universitaetsallee GW1 Block A
Institute of Shipping Economics		W-2800 Bremen 33
and Logistics  (ISL)			Fed. Rep. Germany
email: a08l@alf.zfn.uni-bremen.de
phone: +49-421-22096-20			FAX :  +49-421-22096-55
-------------------------------------------------------------------------------
From: caronni@nessie.cs.id.ethz.ch (Germano Caronni)
Newsgroups: comp.soft-sys.andrew
Subject: Switching between fields
Date: 21 Dec 92 17:18:20 GMT
Distribution: world
Organization: The Internet
X-Unparsable-Date: Mon, 21 Dec 92 17:57:37 CET

Hi,
I have an inset containing several text-input fields, constructed
with arbcon. And each time the user types in a string and confirms
it with 'return' , I would like to switch the cursor to the next input 
field. Currently I am trying this by doing this: in the user-part of
the Routines:

static void subjectCallBack(self,val,r1,r2)
struct confv *self;
struct value *val;
long r1,r2;
{
if(r2 == value_OBJECTDESTROYED) {
        if(self->subject == val) self->subject = NULL;
}
{
/* user code begins here for subjectCallBack */
                                                           /*--START--*/
    enterstrV_WantInputFocus(self->memberListView,self->memberListView);
                                                           /*---END---*/
/* user code ends here for subjectCallBack */
}

But this doesn't work. Has anybody an helping idea ?
Friendly greetings & merry christmas,

		Germano Caronni

--
Instruments register only through things they're designed to register.
Space still contains infinite unknowns.

Germano Caronni    caronni@nessie.cs.id.ethz.ch
From: Wilfred.Hansen@CS.CMU.EDU
Newsgroups: comp.soft-sys.andrew
Subject: Re: troff/eqn -- ez/eq
Date: 21 Dec 92 15:46:51 GMT
Organization: The Internet


Indeed, rofftext does nothing useful with eqn pieces.  Sigh.

It should be straightforward to extend it to handle .EQ and the dits
that come after.  If there is enough demand, we may be able to do so; or
perhaps someone else would be able to take a crack at it.

In the other direction, eprint -t will convert eq insets into eqn.  One
could work in ez and then convert to troff for further editing.  (The
troff is a bit raw.  It uses the -matk macros, which are not as high
level as -ms or -me.)

Fred Hansen
From: ap1i+@ANDREW.CMU.EDU ("Andrew C. Plotkin")
Newsgroups: comp.soft-sys.andrew
Subject: Fwd: Some basic Andrew questions
Date: 22 Dec 92 21:53:36 GMT
Organization: The Internet

The following was sent to me, apparently under the impression that I'm
in charge of something...


Return-path: <grasso@Cards.COM>
X-Andrew-Authenticated-as: 0;andrew.cmu.edu;Network-Mail
Received: from po3.andrew.cmu.edu via trymail
          ID </afs/andrew.cmu.edu/usr15/ap1i/Mailbox/wfBsmYq00UkTAaqk5R>;
          Tue, 22 Dec 1992 16:46:13 -0500 (EST)
Received: from dealer.Cards.COM by po3.andrew.cmu.edu (5.54/3.15) id
<AA09943@X> for ap1i+; Tue, 22 Dec 92 16:46:09 EST
Received: from cribbage.cards (cribbage.cards.com) by dealer.Cards.COM
(4.1/mls/3.2) 
	id AA03550; Tue, 22 Dec 92 16:46:53 EST
Date: Tue, 22 Dec 92 16:46:53 EST
From: grasso@Cards.COM (David Grasso)
Message-Id: <9212222146.AA03550@dealer.Cards.COM>
To: ap1i+@andrew.cmu.edu
Subject: Some basic Andrew questions

Mr. Plotkin,

I recently found the Andrew site and have been looking at the demo, etc.
with my main interest in the Table spreadsheet.  I work on a reusable
software project for the Air Force and am part of the Software
Evaluation Team.  Presently, I am looking for spreadsheet software,
which is either Public Domain or Governmental-off-the-shelf software.

Anyway, I was wondering about Table.  Is it a stand-alone package (able
to be used without the rest of the Andrew world)?  Is it a
full-functioning spreadsheet, or basic token spreadsheet, to be used for
simple applications? Finally, can Table produce graphs and/or charts to
represent the spreadsheet data?  Or can it be used in conjunction with a
graphics package to create graphs/charts?

Thank you for your time.  I'm sorry for the "naivete" of these
questions, but I wasn't able to find docs on Table in the Table subdir
on emsworth.andrew.cmu.edu and didn't come across too much on Table in
the running demo which I logged into.

If Table is not to be recommended, is there any spreadsheet software
that you would suggest which would be Public Domain or governmentally
developed??

Thank you!
dave
grasso@cards.com