RE: [9fans] gcc trouble

RE: [9fans] gcc trouble

[cej]

> I believe that plan9 needs a C++ compiler (I know that you disagree). 

Yes, I disagree. However, I would *love* to have (working) C++ for porting existing progs I need :-(
before I hire a programmer to rewrite them to (Plan9's) C.

++pac.


---
Odchozí zpráva neobsahuje viry.
Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz).
Verze: 6.0.541 / Virová báze: 335 - datum vydání: 14. 11. 2003
 

RE: [9fans] gcc trouble

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 69 bytes --]

how many of those do you think could be handled by a recent cfront?

[-- Attachment #2: Type: message/rfc822, Size: 2526 bytes --]

From: <cej@gli.cas.cz>
To: <9fans@cse.psu.edu>
Subject: RE: [9fans] gcc trouble
Date: Fri, 21 Nov 2003 08:08:51 +0100
Message-ID: <ACCF003CBA3D09458207DB0CB86AD17D124C39@XMAIL.asuch.cas.cz>





> I believe that plan9 needs a C++ compiler (I know that you disagree). 

Yes, I disagree. However, I would *love* to have (working) C++ for porting existing progs I need :-(
before I hire a programmer to rewrite them to (Plan9's) C.

++pac.


---
Odchozí zpráva neobsahuje viry.
Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz).
Verze: 6.0.541 / Virová báze: 335 - datum vydání: 14. 11. 2003
 

RE: [9fans] gcc trouble

[Skip Tavakkolian]

> how many of those do you think could be handled by a recent cfront?

Just curious, how recent is "recent"?

[9fans] gcc trouble

[cej]

>> It would be nice if we got to a systematic way to do this, as it is a 
>> shame to lose all the work each time there's a new version of 
>> GNUmumble.x.y.z.
>> 
>> Just a thought, you're probably all doing this anyway :-)

> I can't speak for anyone else, but I am doing this. :)

I'm a 'pig porter' thus I don't do it :-(
Could someone lead me, in an idiotic way, step by step? It would make me to learn quicker, hopefully!

thanks, ++pac.

---
Odchozí zpráva neobsahuje viry.
Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz).
Verze: 6.0.536 / Virová báze: 331 - datum vydání: 3. 11. 2003
 

[9fans] gcc trouble

[cej]

>  when you compile with gcc make sure you link the libraries from
>  /386/lib/gnu/...  you should have them all there.

Wow! That's it! -lbsd was sufficient. Thanks a lot!
++pac.


---
Odchozí zpráva neobsahuje viry.
Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz).
Verze: 6.0.536 / Virová báze: 331 - datum vydání: 3. 11. 2003
 

[9fans] gcc trouble

[cej]

Hi,

I ran into a (supposedly trivial) problem while linking using gcc:

term% gnu/gsh
$ make
make: *** No targets specified and no makefile found.  Stop.
$ make -f makefile
[blah blah....]
gcc -O6 -Wall -o carnac main.o get_sequences.o find_blocks.o print_alignment.o types.o find_stems.o correlate.o fold.o tree.o print_folding.o string.o accumulation.o parse.o graph.o clique.o nuss.o  #-lm #-lefence
string.o(.text+0x43): undefined reference to `strdup'
string.o(.text+0xa3): undefined reference to `strdup'
string.o(.text+0x103): undefined reference to `strdup'
string.o(.text+0x163): undefined reference to `strdup'
string.o(.text+0x319): undefined reference to `strdup'
string.o(.text+0x1b0): more undefined references to `strdup' follow
parse.o(.text+0x811): undefined reference to `getopt'
parse.o(.text+0x922): undefined reference to `optarg'
parse.o(.text+0x946): undefined reference to `optarg'
parse.o(.text+0x96a): undefined reference to `optarg'
parse.o(.text+0x98c): undefined reference to `optarg'
collect2: ld returned 1 exit status
make: *** [carnac] Error 1
$ 

What am I missing?

Cheers,
++pac.

Peter A. Cejchan
Lab of Paleobiology and Paleoecology
Institute of Geology
Academy of Sciences
Rozvojova 135
16502 Prague, Czechia
http://www.gli.cas.cz/home/cejchan


---
Odchozí zpráva neobsahuje viry.
Zkontrolováno antivirovým systémem AVG (http://www.grisoft.cz).
Verze: 6.0.536 / Virová báze: 331 - datum vydání: 3. 11. 2003
 

Re: [9fans] gcc trouble

[mirtchov]

I was having the same problems today! funny...

when you compile with gcc make sure you link the libraries from
/386/lib/gnu/...  you should have them all there.

it's a pity that the gcc port has fallen behind -- ape just
doesn't cut it for some things.  i tried compiling /sys/src/gnu/ape/
today and it complained about lib9c.h, which is nowhere to be found on my
system.  I hacked around it, but then ran into problems trying to find
getsockname(), even though libbsd.a was specified and was in the path
and...

so, porting links will be put on hold for another few months...

andrey

ps: does anyone know if it's possible to link together object files
compiled with pcc and 8c?  how about gcc and 8c/pcc?  say I want to
write the gui for a unix program i'm porting, one option is writing
ape libraries for draw(), the other is writing native draw() code
which links with the rest of the program.  possible?

Re: [9fans] gcc trouble

[Russ Cox]

> ps: does anyone know if it's possible to link together object files
> compiled with pcc and 8c?

yes.  pcc is just a wrapper around 8c.

> how about gcc and 8c/pcc?

no.  these object files are completely different format.

> say I want to
> write the gui for a unix program i'm porting, one option is writing
> ape libraries for draw(),

yes, this is an option.

> the other is writing native draw() code
> which links with the rest of the program.  possible?

not as much, no.  ape and native plan 9 c code can't
be mixed too easily since, for example, they have
different open, read, write, etc.  if you got the
linking order correct (which would be a pain) then
perhaps (perhaps!) libdraw could manage to use the
ape open, but it would still need to pull in the libc
utf routines and probably others.  like fork or wait.
and as soon as you touch libthread you might as well
give up.  anything is possible, but this is not worth
the trouble.

another option is writing the code in native plan 9 style
and using the porting library, which does include libdraw.

Re: [9fans] gcc trouble

[mirtchov]

>> ps: does anyone know if it's possible to link together object files
>> compiled with pcc and 8c?
>
> yes.  pcc is just a wrapper around 8c.
>

but when I try to compile a Plan 9 C program with pcc it complains
about not being able to find draw.h and friends...

here's the situation, see if you can give me an advice:

	- the png viewer in Plan 9 is broken and has been for a while

	- i can't find the bug (libflate is suspect) so i decide to
	use the default libpng library, which in turn uses the unix
	zlib, both of which are in /sys/src/cmd/gs/

	- i compile both zlib and libpng using pcc.  the pngtest.c
	program that comes with libpng works when compiled with pcc,
	though it never displays anything on the screen (it just
	verifies that it can read png files)

	- i write a very basic 'pngtest' program for Plan 9, which
	uses the same library, however when compiled with 8c it hangs
	on trying to parse all the horrible #if's in png.h, and when
	compiled with pcc it has no understanding of draw()
	commands...

any ideas?

andrey

Re: [9fans] gcc trouble

[Russ Cox]

> >> ps: does anyone know if it's possible to link together object files
> >> compiled with pcc and 8c?
> >
> > yes.  pcc is just a wrapper around 8c.
> >
>
> but when I try to compile a Plan 9 C program with pcc it complains
> about not being able to find draw.h and friends...

you only asked about linking.  as i said later in the message,
trying to mix plan 9 c libraries with ape libraries
is not a good idea.

Re: [9fans] gcc trouble

[mirtchov]

> here's the situation, see if you can give me an advice:

bah, i'll do what everybody else does -- beat the source into
submission, or until it compiles under plan9.

i really want a png viewer :)

Re: [9fans] gcc trouble

[Christopher Nielsen]

On Fri, Nov 07, 2003 at 12:48:36PM -0700, mirtchov@cpsc.ucalgary.ca wrote:
>
> bah, i'll do what everybody else does -- beat the source into
> submission, or until it compiles under plan9.

that and rewriting the makefiles is what i had to do to
get flac (free lossless audio compression) working. the
build infrastructure for flac is atrocious; i won't even
talk about the source. it's not in any shape to be a port,
but if i spend a little more time on it, it might be. i
don't know that anyone but me is interested, though.

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] gcc trouble

[ron minnich]

It might be useful for all of you doing ports to put the original source
tree somewhere and bind a new tree on top of it for modified files; or
find some other nice way to keep track of changes. With any luck we can
develop a patchset that can be supplied back to the creators and possibly
to new versions of the code as the new versions appear.

It would be nice if we got to a systematic way to do this, as it is a
shame to lose all the work each time there's a new version of
GNUmumble.x.y.z.

Just a thought, you're probably all doing this anyway :-)

ron

Re: [9fans] gcc trouble

[Christopher Nielsen]

On Fri, Nov 07, 2003 at 01:47:16PM -0700, ron minnich wrote:
>
> Just a thought, you're probably all doing this anyway :-)

I can't speak for anyone else, but I am doing this. :)

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] gcc trouble

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 166 bytes --]

>>	uses the same library, however when compiled with 8c it hangs
>>	on trying to parse all the horrible #if's in png.h, and when

try the -p option for ansi cpp.

[-- Attachment #2: Type: message/rfc822, Size: 2963 bytes --]

From: mirtchov@cpsc.ucalgary.ca
To: 9fans@cse.psu.edu
Subject: Re: [9fans] gcc trouble
Date: Fri, 7 Nov 2003 12:14:03 -0700
Message-ID: <d5962c41958722d2829dbb07a0753455@plan9.ucalgary.ca>

>> ps: does anyone know if it's possible to link together object files
>> compiled with pcc and 8c?
>
> yes.  pcc is just a wrapper around 8c.
>

but when I try to compile a Plan 9 C program with pcc it complains
about not being able to find draw.h and friends...

here's the situation, see if you can give me an advice:

	- the png viewer in Plan 9 is broken and has been for a while

	- i can't find the bug (libflate is suspect) so i decide to
	use the default libpng library, which in turn uses the unix
	zlib, both of which are in /sys/src/cmd/gs/

	- i compile both zlib and libpng using pcc.  the pngtest.c
	program that comes with libpng works when compiled with pcc,
	though it never displays anything on the screen (it just
	verifies that it can read png files)

	- i write a very basic 'pngtest' program for Plan 9, which
	uses the same library, however when compiled with 8c it hangs
	on trying to parse all the horrible #if's in png.h, and when
	compiled with pcc it has no understanding of draw()
	commands...

any ideas?

andrey

Re: [9fans] gcc trouble

[mirtchov]

that's what I'm currently doing (-p).. still too many dependencies on lunix-y things. I'm butchering them down one by one.

Re: [9fans] gcc trouble

[Latchesar Ionkov]

On Fri, Nov 07, 2003 at 11:53:38AM -0500, Russ Cox said:
> > ps: does anyone know if it's possible to link together object files
> > compiled with pcc and 8c?
>
> yes.  pcc is just a wrapper around 8c.
>
> > how about gcc and 8c/pcc?
>
> no.  these object files are completely different format.

Why is it using another format?

Thanks,
	Lucho

Re: [9fans] gcc trouble

[Russ Cox]

> > > how about gcc and 8c/pcc?
> >
> > no.  these object files are completely different format.
>
> Why is it using another format?

because ken uses nice simple object files
(which are more like binary assembler input than, say, x86 code)
and gcc uses the traditional complicated object files.

Re: [9fans] gcc trouble

[Latchesar Ionkov]

On Fri, Nov 07, 2003 at 08:35:07PM -0500, Russ Cox said:
> > > > how about gcc and 8c/pcc?
> > >
> > > no.  these object files are completely different format.
> >
> > Why is it using another format?
>
> because ken uses nice simple object files
> (which are more like binary assembler input than, say, x86 code)
> and gcc uses the traditional complicated object files.

Is it possible to make gcc to create plan9 object files?

Having two sets of deveopment tools is not very convenient. For example I
can't use truss module to trace a C++ program.

Thanks,
	Lucho

Re: [9fans] gcc trouble

[Russ Cox]

> Is it possible to make gcc to create plan9 object files?
>
> Having two sets of deveopment tools is not very convenient. For example I
> can't use truss module to trace a C++ program.
>
> Thanks,
> 	Lucho

anything's possible.  we don't have anyone with the time
and the inclination to work on gcc though.

Re: [9fans] gcc trouble

[ron minnich]

On Fri, 7 Nov 2003, Latchesar Ionkov wrote:

> Is it possible to make gcc to create plan9 object files?

you can create pretty much anything you want with the bfd backend, so I'm
not sure why it's not making plan 9 object files now, unless it is the
impossibility of figuring that code out ...

ron

Re: [9fans] gcc trouble

[Geoff Collyer]

I have a hazy memory of g++ relying on features or behaviour of gnuld.
Otherwise, one could make gcc generate Plan 9 assembly language and
assemble it with 8a and friends.

Re: [9fans] gcc trouble

[ron minnich]

On Fri, 7 Nov 2003, Geoff Collyer wrote:

> I have a hazy memory of g++ relying on features or behaviour of gnuld.
> Otherwise, one could make gcc generate Plan 9 assembly language and
> assemble it with 8a and friends.

I think the right place to catch it is at the back of gnuld. Build a bfd
module that does plan 9 object format, and use the -o switch to ld to get
that format.

Here are the formats supported by linux on my laptop:
BFD header file version 2.11.93.0.2 20020207
elf32-i386
 (header little endian, data little endian)
  i386
a.out-i386-linux
 (header little endian, data little endian)
  i386
efi-app-ia32
 (header little endian, data little endian)
  i386
elf32-little
 (header little endian, data little endian)
  i386
elf32-big
 (header big endian, data big endian)
  i386
srec
 (header endianness unknown, data endianness unknown)
  i386
symbolsrec
 (header endianness unknown, data endianness unknown)
  i386
tekhex
 (header endianness unknown, data endianness unknown)
  i386
binary
 (header endianness unknown, data endianness unknown)
  i386
ihex
 (header endianness unknown, data endianness unknown)
  i386
trad-core
 (header endianness unknown, data endianness unknown)

               elf32-i386 a.out-i386-linux efi-app-ia32 elf32-little
elf32-big
          i386 elf32-i386 a.out-i386-linux efi-app-ia32 elf32-little
elf32-big

               srec symbolsrec tekhex binary ihex trad-core
          i386 srec symbolsrec tekhex binary ihex ---------

Note that symbolsrec format. srec long ago was actually a paper tape
format at one point, moved to serial ports, and still around almost 30
years later. If you can do srec, you can do plan 9 a.out.

The next mess you face is dealing with calling conventions, ewwww.

ron

Re: [9fans] gcc trouble

[Charles Forsyth]

>>I think the right place to catch it is at the back of gnuld. Build a bfd
>>module that does plan 9 object format, and use the -o switch to ld to get
>>that format.

the plan 9 object files (if you mean .8 etc) are binary, but not binary object code.
they contain instructions in a symbolic form.  only the loader knows
the machine encoding, and it does final machine instruction selection.

gnu ld looks fairly conventional: the linker doesn't really know much about the machine
instructions, but applies some relocation functions on command of the
assembler or compiler in a fairly mechanical if complex way.

you'd therefore need to disassemble the code inside gnu ld to produce .8
files.  mind you, given the size of bfd--it takes 161,177 lines in 92 files to handle
all the different elf variants in the copy i've got--it would hardly be noticed.
elflink.h alone is 6332 lines (but elf-like it cunningly contains reams of static functions).
put one elf that size in Lord of the Rings and even Sauron would have been
given pause for thought.  they'd also have had to send out for bigger film.

Re: [9fans] gcc trouble

[ron minnich]

On Sat, 8 Nov 2003, Charles Forsyth wrote:

> the plan 9 object files (if you mean .8 etc) are binary, but not binary
> object code.

oops, yeah, I forgot that. Just ignore me.

ron

Re: [9fans] gcc trouble

[Douglas A. Gwyn]

Charles Forsyth wrote:
> the plan 9 object files (if you mean .8 etc) are binary, but not binary object code.
> they contain instructions in a symbolic form.  only the loader knows
> the machine encoding, and it does final machine instruction selection.
> ...
> you'd therefore need to disassemble the code inside gnu ld to produce .8
> files.

Not unless you need to link gcc-compiled code against .8
libraries.  I assume the libraries could be rebuilt in ELF
format by recompiling with the putative Plan9 gcc.  Without
even looking, one knows that there has to be a way to embed
binary data within .8 object files, so just copy the linked
image out as binary data within the .8 file.

Re: [9fans] gcc trouble

[Latchesar Ionkov]

I think I found one of the reasons -- gcc puts the C++ templates code in
.gnu.linkonce.* sections.

I guess (didn't look into it) Plan9 object format doesn't support sections
with arbitrary names.

	Lucho

On Fri, Nov 07, 2003 at 08:57:04PM -0800, Geoff Collyer said:
> I have a hazy memory of g++ relying on features or behaviour of gnuld.
> Otherwise, one could make gcc generate Plan 9 assembly language and
> assemble it with 8a and friends.

Re: [9fans] gcc trouble

[Charles Forsyth]

>>I guess (didn't look into it) Plan9 object format doesn't support sections
>>with arbitrary names.

it isn't the usual object format:
see thompson's paper on the compiler (to begin with).

Re: [9fans] gcc trouble

[Latchesar Ionkov]

Hi,

I spend some time researching how to make gcc to produce Plan9 object format.

Creating a new BFD backend that generates Plan9 object files won't solve the
problem. GCC uses different calling convention, so even if we make libbfd to
produce Plan9 object format, the object files won't be compatible with
object files created by 8c.

I think the only solution is to change GCC machine description for Plan9. It
may even be possible to make gcc to generate Plan9 object files instead of
assembler files. So far I see four major tasks:

1. Change target's calling convention. This also includes finding out if the
change will affect C++ exception handling.

2. Change assembler syntax to be compatible with 8a, or make GCC to generate
Plan9 object files directly.

3. Teach 8l (and 8a) about the additional instructions that GCC can produce
(MMX, SSE etc.), or make GCC to not use them.

4. Modify 8l to support multiple definitions of GLOBAL DATA symbols, placing
only one in the image (similar to setting bit 2 of the TEXT symbol flags).

Any thoughts?

Thanks,
	Lucho

On Wed, Nov 12, 2003 at 11:46:19PM +0000, Charles Forsyth said:
> >>I guess (didn't look into it) Plan9 object format doesn't support sections
> >>with arbitrary names.
>
> it isn't the usual object format:
> see thompson's paper on the compiler (to begin with).

Re: [9fans] gcc trouble

[boyd, rounin]

> 2. Change assembler syntax to be compatible with 8a, or make GCC to generate
> Plan9 object files directly.
>
> 3. Teach 8l (and 8a) about the additional instructions that GCC can produce
> (MMX, SSE etc.), or make GCC to not use them.

i'd rip gcc apart and get it to generate valid input to 8a.  be a bugger of
a job though.  is it worth the effort?

i don't see the point in smashing perfectly usuable tools to cater for one.

Re: [9fans] gcc trouble

[Latchesar Ionkov]

On Thu, Nov 20, 2003 at 07:34:24PM +0100, boyd, rounin said:
> > 2. Change assembler syntax to be compatible with 8a, or make GCC to generate
> > Plan9 object files directly.
> >
> > 3. Teach 8l (and 8a) about the additional instructions that GCC can produce
> > (MMX, SSE etc.), or make GCC to not use them.
>
> i'd rip gcc apart and get it to generate valid input to 8a.  be a bugger of
> a job though.  is it worth the effort?

I believe that plan9 needs a C++ compiler (I know that you disagree).

	Lucho

Re: [9fans] gcc trouble

[boyd, rounin]

> I believe that plan9 needs a C++ compiler (I know that you disagree).

so C# is next, right?

Re: [9fans] gcc trouble

[mirtchov]

>> I believe that plan9 needs a C++ compiler (I know that you disagree).
>
> so C# is next, right?

I hope a decent browser is in there somewhere :)

Re: [9fans] gcc trouble

[Latchesar Ionkov]

On Thu, Nov 20, 2003 at 10:27:53PM +0100, boyd, rounin said:
> > I believe that plan9 needs a C++ compiler (I know that you disagree).
>
> so C# is next, right?

Only if somebody pays for it :)

	Lucho

Re: [9fans] gcc trouble

[Fco.J.Ballesteros]

> I believe that plan9 needs a C++ compiler (I know that you disagree).
>
> 	Lucho

Go for it.

Re: [9fans] gcc trouble

[Joel Salomon]

> 3. Teach 8l (and 8a) about the additional instructions that GCC can
> produce (MMX, SSE etc.), or make GCC to not use them.
>

Adding the MMX/SSE instructions might not be a bad idea on its own, on the
off chance that some multimedia code gets ported to plan 9. After this
semester is done I'll try my hand at it.

IIRC, one/some of the 5273 options to gcc configure controls whether MMX
instructions are generated.

--Joel

Re: [9fans] gcc trouble

[Peter Bosch]

>> 3. Teach 8l (and 8a) about the additional instructions that GCC can
>> produce (MMX, SSE etc.), or make GCC to not use them.
>>
>
> Adding the MMX/SSE instructions might not be a bad idea on its own, on the
> off chance that some multimedia code gets ported to plan 9. After this
> semester is done I'll try my hand at it.

I have a 8a and 8l with support for MMX -- believe it or not, I used it
to implement UMTS encryption.  I'll see if I can merge my version of
8a and 8l in the regular tree.

Here's a sample of the assembly:

	/* y0 */
	MOVQ	0(AX),MM0	/* MM0: x0 */
	MOVQ	8(AX),MM1	/* MM1: x1 */
	MOVQ	16(AX),MM2	/* MM2: x2 */
	MOVQ	40(AX),MM3	/* MM3: x5 */
	MOVQ	56(AX),MM4	/* MM4: x7 */
	MOVQ	64(AX),MM5	/* MM5: x8 */
	MOVQ	MM0,MM7	/* MM7: x0 */
	PAND	MM2,MM7	/* MM7: x0x2 */
	PXOR	24(AX),MM7
	MOVQ	MM2,MM6	/* MM6: x2 */
	PAND	MM3,MM6	/* MM6: x2x5 */
	PXOR	MM6,MM7
	MOVQ	MM3,MM6	/* MM6: x5 */
	PAND	48(AX),MM6	/* MM6: x5x6 */
	PXOR	MM6,MM7

peter.

Re: [9fans] gcc trouble

[Christopher Nielsen]

On Thu, Nov 20, 2003 at 02:27:51PM -0500, Joel Salomon wrote:
>
> Adding the MMX/SSE instructions might not be a bad idea on its own, on the
> off chance that some multimedia code gets ported to plan 9. After this
> semester is done I'll try my hand at it.

they're useful for more than just multimedia code. they're
beneficial for crypto operations, as well.

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] gcc trouble

[boyd, rounin]

> they're useful for more than just multimedia code. they're
> beneficial for crypto operations, as well.

they may be useful, but they're not general.

Re: [9fans] gcc trouble

[Joel Salomon]

> they may be useful, but they're not general.
>
Thats a valid argument for not having the compiler know about them. We're
discussing the assembler. Or did you mean to argue their existence on the
chip? I can't see that adding *another* kluge atop IA32 can possibly hurt.

--Joel

Re: [9fans] gcc trouble

[boyd, rounin]

> > they may be useful, but they're not general.
> >
> Thats a valid argument for not having the compiler know about them. We're
> discussing the assembler. Or did you mean to argue their existence on the
> chip? I can't see that adding *another* kluge atop IA32 can possibly hurt.

well i can.  you can't do it from the compiler, unless it knows a lot.  one of
the goals of the plan 9 compilers was to make them general.  if you want
to do some specific task then do it, but don't break the compiler.

writing assembler is a waste of time, unless you have a _really good reason_.

Re: [9fans] gcc trouble

[Christopher Nielsen]

On Thu, Nov 20, 2003 at 06:11:46PM -0500, Joel Salomon wrote:
>
> Thats a valid argument for not having the compiler know about them. We're
> discussing the assembler. Or did you mean to argue their existence on the
> chip? I can't see that adding *another* kluge atop IA32 can possibly hurt.

I don't really think adding SIMDs (a.k.a. vector processors)
,what MMX/SSE are, to the chip was a kludge for IA32. They
have a few uses. Touting it as being the best thing since
sliced bread for multimedia is a bit much, though. FWIW,
PowerPC has SIMDs, too. It's called AltiVec.

There's an interesting paper about using AltiVec for crypto
here:

http://www.simdtech.org/apps/group_public/download.php/22/Cryptography.pdf

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] gcc trouble

[boyd, rounin]

> There's an interesting paper about using AltiVec for crypto ...

that was my immediate thought:  crypto

Re: [9fans] gcc trouble

[Joel Salomon]

> Is it possible to make gcc to create plan9 object files?

I would guess that is would be easiest to output assembly from gcc, and
convert from gas format to 9a format.

--Joel